From infinity@lindenlab.com Wed Jul 1 13:11: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 BEF553A6CFB for ; Wed, 1 Jul 2009 13:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[AWL=0.230, 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 g6-A9Cl5JehG for ; Wed, 1 Jul 2009 13:11:14 -0700 (PDT) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.210.182]) by core3.amsl.com (Postfix) with ESMTP id EC6C03A6838 for ; Wed, 1 Jul 2009 13:11:13 -0700 (PDT) Received: by yxe12 with SMTP id 12so1821215yxe.29 for ; Wed, 01 Jul 2009 13:11:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.138.8 with SMTP id l8mr14038779and.32.1246479093802; Wed, 01 Jul 2009 13:11:33 -0700 (PDT) In-Reply-To: <20090630135751.GA24477@alinoe.com> References: <20090629161121.GA17251@alinoe.com> <20090629161815.GB17251@alinoe.com> <591737.89462.qm@web82608.mail.mud.yahoo.com> <3a880e2c0906291219t1990272fkb276979ebc97d292@mail.gmail.com> <897153.73396.qm@web82601.mail.mud.yahoo.com> <4A4926EE.5060509@lindenlab.com> <20090630135751.GA24477@alinoe.com> Date: Wed, 1 Jul 2009 13:11:33 -0700 Message-ID: <3a880e2c0907011311t6e989ca0vc2312e2deb3b7587@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] A Review of Multi-Domain Use Cases [Was: Re: OpenID and OGP : beginning the discussion ...] 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, 01 Jul 2009 20:11:14 -0000 cool. i think we're in violent agreement. > Therefore, I'd like to propose this: > > =A01. Arbitrary in-world name tags, which have only one intent: to provid= e a > =A0 =A0customer-satisfying visual name. > =A02. Globally unique identifiers, either UUID or formed by composition o= f N-part > =A0 =A0local name @ issuing authority, that remain the same over logins f= or any > =A0 =A0given account and that are passed to every viewer that receives 1)= . > =A03. Entirely separate authentication credentials, in other words, unrel= ated to > =A0 =A01) or 2). From belxjander@gmail.com Mon Jul 6 03:54: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 8973A3A6BB9 for ; Mon, 6 Jul 2009 03:54:30 -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=[BAYES_00=-2.599, SARE_RMML_Stock10=0.13] 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 g1PT+eVeVigi for ; Mon, 6 Jul 2009 03:54:29 -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 A730528C2F4 for ; Mon, 6 Jul 2009 03:53:43 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id f9so1098722rvb.49 for ; Mon, 06 Jul 2009 03:54:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:disposition-notification-to:content-type:date:message-id :mime-version:x-mailer:content-transfer-encoding; bh=qCDZW0iTkNz+8MRg+56grvtRQZbywr0y5V+lhGUg38g=; b=Sfy71MWJrAMOFg9uCrKwwm/G1TjD1XiAmSwXBdct4wmxj7j4u1M4VSgcBUbqL4xYOR 9qxlcBCkEfWv8OXNfvs/Hev78OnvVGmnsZkyqD2e8GlXGgA219KnU98Wh1CeNqUvPCKu kH6t9FDoMA1SKlFX8liYSNvPxormwOweFPA7g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:disposition-notification-to :content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; b=j/HdpFik0f7WdQ03Pe6KbDRWxa1y5PUkXPkh55G8DgQAklUGmcwnooW8QmAwvh30N+ CshWXZpqSQalvs1UXP6X+Wt9G/AT3ZKz2eGyJgP6scXgdYejiyEwzbh/S6xWXaiynhSs eP/i4ef6GLQF8sL79Dq5Ee49ewHlTEq4i6eME= Received: by 10.140.203.3 with SMTP id a3mr2225738rvg.238.1246877640468; Mon, 06 Jul 2009 03:54:00 -0700 (PDT) Received: from ?10.2.1.3? (p3146-ipbfp203tottori.tottori.ocn.ne.jp [123.226.140.146]) by mx.google.com with ESMTPS id k37sm27749973rvb.48.2009.07.06.03.53.57 (version=SSLv3 cipher=RC4-MD5); Mon, 06 Jul 2009 03:53:58 -0700 (PDT) From: Kajikawa Jeremy To: ogpx@ietf.org In-Reply-To: <3a880e2c0906280906if8f9791h89a9bc13a7170b53@mail.gmail.com> References: <3a880e2c0906280906if8f9791h89a9bc13a7170b53@mail.gmail.com> Content-Type: text/plain Date: Mon, 06 Jul 2009 17:56:53 +0900 Message-Id: <1246870613.11996.23.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.26.2 Content-Transfer-Encoding: 7bit Subject: Re: [ogpx] Global Agent Domain Registry [Was: Re: OpenID and OGP : beginning the discussion ...] 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, 06 Jul 2009 10:54:30 -0000 Why not a simple option of including an "@domain" extra identifier? when interacting with multiple domains... Each domain keeps an own registry and cross-domain relations can use a pre-agreed Domain ID... That way anyone can use a given name but confusion is avoided since there are people already existing with the same name that I am already aware of (R.W. solution is middle initial or other seperator when together) Why not re-use an already usable social custom and define for any interop across "Agent Domain"s ... similar to "somename@hotmail.com" being different to "somename@gmail.com", and I would suggest use of the Originating AgentDomain as being the seperator for this use case of multiple-same-name Avatars On Sun, 2009-06-28 at 09:06 -0700, Infinity Linden wrote: > okay... so it seems like you're actually asking... "how do we maintain > global avatar name uniqueness if avatar first and last name are used > as primary keys for logging in?" > > there was some discussion about a global avatar name registry last > year in the SL Architecture Working Group, though i don't think there > were any definitive results. > > i think we're punting on the problem with respect to protocol > development. that is, i don't think the protocol specifications will > say anything about the expectation that an agent name be globally > unique across grids. > > deploying such a service would be quite an effort in terms of community buy-in. > > that being said, there's no reason it can't be done in the future or > as a project of a non-IETF group. > > for the time being, we can use account identifiers to guarantee > uniqueness; or at least that's my sense given the lack of radical > agreement in the topic. > > in other words, i think it's a topic that will lead to wailing and > gnashing of teeth and would only serve to delay production of > standards that people _do_ agree on. > > On Sun, Jun 28, 2009 at 5:34 AM, Carlo Wood wrote: > > I'm glad it doesn't imply that then :p > > > > Nevertheless, it worries me a bit. At some point we want to be able to > > teleport between grids right? Surely the people will want to have the > > same name (and shape) after they teleported in most cases. > > > > If the same first_name+last_name is only unique per grid, then > > people will (have to) start fights about names: one has to register > > the same first_name+last_name on every grid you want to use. > > > > The make a long story short: they same wars and trouble will immerse > > as are happening on IRC now: too many people in a too small namespace. > > > > At some point there will come the strong demand for a "nick serv", > > some central point where people can reserve their name for every > > large grid on the planet and claim for themselves (for example, to > > stop forms of impersonations). That would be 'hack'. > > > > I think we have to seriously think about this. Perhaps there is a > > better solution than 'first name / last name' to login ;). > > > > On Sat, Jun 27, 2009 at 03:54:08PM -0700, Infinity Linden wrote: > >> why would this imply global uniqueness? it describes a message sent > >> from a client to a particular protocol endpoint. > >> > >> On Sat, Jun 27, 2009 at 3:33 AM, Carlo Wood wrote: > >> >> & identifier = { > >> >> type: 'account', > >> >> account_name: string, > >> >> first_name: string, > >> >> last_name: string, > >> >> } > >> >> > >> >> & identifier = { > >> >> type: 'agent', > >> >> first_name: string, > >> >> last_name: string, > >> >> } > >> > > >> > This seems to implicate that first_name + last_name > >> > have to be unique not only per grid, but globally > >> > for every virtual world. > >> > > >> > Is that true? Or would it be possible to use a different > >> > name on different grids? Would it be possible that different > >> > unrelated people use the same name on different grids? > > > > -- > > Carlo Wood > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx From infinity@lindenlab.com Mon Jul 6 11:17: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 88F7E3A6D11 for ; Mon, 6 Jul 2009 11:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.755 X-Spam-Level: X-Spam-Status: No, score=-1.755 tagged_above=-999 required=5 tests=[AWL=0.222, 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 fUqsKp9zY+ko for ; Mon, 6 Jul 2009 11:17:42 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by core3.amsl.com (Postfix) with ESMTP id 14FD33A6D2B for ; Mon, 6 Jul 2009 11:17:41 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c37so1594312anc.4 for ; Mon, 06 Jul 2009 11:16:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.32.6 with SMTP id f6mr8858449anf.143.1246904198325; Mon, 06 Jul 2009 11:16:38 -0700 (PDT) Date: Mon, 6 Jul 2009 11:16:38 -0700 Message-ID: <3a880e2c0907061116r670f8d19t75afd7f4ab733ae1@mail.gmail.com> From: Infinity Linden To: ogpx@ietf.org Content-Type: multipart/mixed; boundary=0016e6476e76cf675e046e0d8170 Subject: [ogpx] revised draft charter for OGPX working group 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, 06 Jul 2009 18:17:43 -0000 --0016e6476e76cf675e046e0d8170 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit thanks to the many people who offered suggestions concerning the OGPX draft charter, we now have a new revision. please look it over, especially if you're attending the BoF in Stockholm. -cheers -meadhbh hamrick --0016e6476e76cf675e046e0d8170 Content-Type: application/xhtml+xml; name="ogpx-draft-charter.xhtml" Content-Disposition: attachment; filename="ogpx-draft-charter.xhtml" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fwtiiy0t0 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPCFET0NUWVBFIGh0bWwgUFVC TElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgU3RyaWN0Ly9FTiIKICAgICAgICAgICAgICAgICAg ICAgICJodHRwOi8vd3d3LnczLm9yZy9UUi94aHRtbDEvRFREL3hodG1sMS1zdHJpY3QuZHRkIj4K PGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiPgogIDxoZWFkPgogICAg PHRpdGxlPk9HUFggV29ya2luZyBHcm91cCBEcmFmdCBDaGFydGVyPC90aXRsZT4KICA8L2hlYWQ+ CiAgPGJvZHk+CiAgICA8aDE+V29ya2luZyBHcm91cCBOYW1lOjwvaDE+CiAgICA8cD5PcGVuIEdy aWQgUHJvdG9jb2wgKE9HUFgpPC9wPgoKICAgIDxoMT5DaGFpcnM6PC9oMT4KICAgIDxwPlRCRDwv cD4KCiAgICA8aDE+QXJlYSBhbmQgQXJlYSBEaXJlY3RvcnM6PC9oMT4KICAgIDxwPkFwcGxpY2F0 aW9ucyBBcmVhPC9wPgogICAgPHA+TGlzYSBEdXNzZWF1bHQgJmx0O2xpc2EuZHVzc2VhdWx0QG1l c3NhZ2luZ2FyY2hpdGVjdHMuY29tJmd0OzwvcD4KICAgIDxwPkFsZXhleSBNZWxuaWtvdiAmbHQ7 YWxleGV5Lm1lbG5pa292QGlzb2RlLmNvbSZndDs8L3A+CgogICAgPGgxPlJlc3BvbnNpYmxlIEFy ZWEgRGlyZWN0b3I6PC9oMT4KICAgIDxwPlRCRDwvcD4KCiAgICA8aDE+TWFpbGluZyBMaXN0Ojwv aDE+CiAgICA8cD4KICAgIG9ncHhAaWV0Zi5vcmcKICAgIDxiciAvPgogICAgaHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29ncHgKICAgIDwvcD4KCiAgICA8aDE+RGVzY3JpcHRp b24gb2YgV29ya2luZyBHcm91cDo8L2gxPgoKICAgIDxwPlZpcnR1YWwgV29ybGRzIChWV3MpIGFu ZCBvdGhlciBNYXNzaXZlbHkgTXVsdGktUGFydHkgT25saW5lCiAgICAgIEFwcGxpY2F0aW9ucyAo TU1PcykgYXJlIG9mIGluY3JlYXNpbmcgaW50ZXJlc3QgdG8gdGhlIEludGVybmV0CiAgICAgIGNv bW11bml0eS4gSW5udW1lcmFibGUgZXhhbXBsZXMgZXhpc3Qgb2Ygc3VjaCBhcHBsaWNhdGlvbnMs IG1vc3QKICAgICAgdXNpbmcgcHJvcHJpZXRhcnkgcHJvdG9jb2xzLiBXaXRoIHRoZWlyIHJvb3Rz IGluIGdhbWVzIGFuZCBzb2NpYWwKICAgICAgaW50ZXJhY3Rpb24sIFZpcnR1YWwgV29ybGRzIGFy ZSBub3cgYmVpbmcgdXNlZCBpbmNyZWFzaW5nbHkgaW4KICAgICAgYnVzaW5lc3MsIGVkdWNhdGlv biBhbmQgaW5mb3JtYXRpb24gZXhjaGFuZ2UuIFdpdGggYSBncm93aW5nIHVzZXIKICAgICAgYmFz ZSwgY3JlYXRvcnMgb2Ygc3VjaCBzeXN0ZW1zIGFyZSBpbnRlcmVzdGVkIGluIGRldmVsb3Bpbmcg YQogICAgICBzdGFuZGFyZCB2aXJ0dWFsIHdvcmxkcyBwcm90b2NvbCB0byBlbmFibGUgaW50ZXJv cGVyYWJpbGl0eS48L3A+CgogICAgPHA+VGhlIG9iamVjdGl2ZSBvZiB0aGUgT0dQWCB3b3JraW5n IGdyb3VwIGlzIHRvIHByb3ZpZGUgYW4KICAgICAgYXBwbGljYXRpb24tbGF5ZXIgd2lyZSBwcm90 b2NvbCBmb3IgVmlydHVhbCBXb3JsZHMgdG8gZW5hYmxlCiAgICAgIGludGVyb3BlcmFiaWxpdHkg YmV0d2VlbiBhcHBsaWNhdGlvbnMgYW5kIHByb3ZpZGUgZm9yIGFjY2VzcyBhbmQKICAgICAgZXhj aGFuZ2Ugd2l0aCBvdGhlciBzeXN0ZW1zIG9uIHRoZSBpbnRlcm5ldCBzdWNoIGFzIHdlYiBzZXJ2 aWNlcywKICAgICAgZS1tYWlsIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzdG9yYWdlIHN5c3RlbXMu IFRoZSBPcGVuIEdyaWQgUHJvdG9jb2wKICAgICAgKE9HUCkgd2lsbCBkZXNjcmliZQogICAgICBz ZW1hbnRpY3MgYW5kIHByb3RvY29sIGludGVyYWN0aW9uIGZvciB0aGUgdmlydHVhbCB3b3JsZCwK ICAgICAgaW5kZXBlbmRlbnQgb2YgdHJhbnNwb3J0LCB0aG91Z2ggYmluZGluZ3MgZm9yIGNhcnJ5 aW5nIE9HUCBvdmVyCiAgICAgIEhUVFAgd2lsbCBiZSBkZWZpbmVkLjwvcD4KCiAgICA8cD5UaGUg Y29yZSB3b3JrIG9mIHRoZSBncm91cCB3aWxsIGJlIHRoZSBwcm9kdWN0aW9uIG9mIHRoZSBPcGVu CiAgICAgIEdyaWQgUHJvdG9jb2wgc3VpdGUgKE9HUCksIGEgc2V0IG9mIGFwcGxpY2F0aW9uIHBy b3RvY29scyB0bwogICAgICBjb21tdW5pY2F0ZSBhbmQgaW50ZXJhY3Qgd2l0aCB0aGUgc3RhdGUg b2YgVmlydHVhbCBXb3JsZAogICAgICBhcHBsaWNhdGlvbnMuIFRoZSBPcGVuIEdyaWQgUHJvdG9j b2wgd2lsbCBkZWZpbmUgdmlydHVhbCB3b3JsZHMgd2l0aAogICAgICB0aGUgZm9sbG93aW5nIGFz c3VtcHRpb25zOjwvcD4KCiAgICA8dWw+CiAgICAgIDxsaT5UaGUgVmlydHVhbCBXb3JsZCBleGlz dHMgaW5kZXBlbmRlbnQgb2YgdGhlIHBhcnRpY2lwYXRpbmcgY2xpZW50cy48L2xpPgogICAgICA8 bGk+VXNlcnMgaGF2ZSBhIHNpbmdsZSwgdW5pcXVlIHByZXNlbmNlIGluIHRoZSB2aXJ0dWFsIHdv cmxkLjwvbGk+CiAgICAgIDxsaT5UaGUgdmlydHVhbCB3b3JsZCBjb250YWlucyBwZXJzaXN0ZW50 IG9iamVjdHMuPC9saT4KICAgICAgPGxpPlRoZSB2aXJ0dWFsIHdvcmxkIG1heSBiZSBwYXJ0aXRp b25lZC48L2xpPgogICAgICA8bGk+UHJlc2VuY2UsIHN0YXRlIGFuZCBzaW11bGF0aW9uIG9jY3Vy IG9uIGF1dGhvcml0YXRpdmUgaG9zdHMuPC9saT4KICAgIDwvdWw+CgogICAgPHA+Rm91bmRhdGlv bmFsIGNvbXBvbmVudHMgb2YgdGhlIE9wZW4gR3JpZCBQcm90b2NvbCBpbmNsdWRlIHRoZSBwdWJs aWNhdGlvbiBvZjwvcD4KICAgIAogICAgPG9sPgogICAgICA8bGk+YW4gYWJzdHJhY3QgZHluYW1p YyBzdHJ1Y3R1cmVkIGRhdGEgc3lzdGVtLCBzdWl0YWJsZSBmb3IgZGVzY3JpYmluZyB0aGUgYXBw bGljYXRpb24gcHJvdG9jb2wgaW4gYSB0cmFuc3BvcnQtbmV1dHJhbCBtYW5uZXIsPC9saT4KICAg ICAgPGxpPmNsZWFyIHNlbWFudGljcyBhbmQgbWVjaGFuaXNtcyBmb3IgY2FycnlpbmcgT0dQIG1l c3NhZ2VzIG92ZXIgbWVzc2FnZS1vcmllbnRlZCB0cmFuc3BvcnRzIHdpdGggcmVxdWVzdC9yZXNw b25zZSBzZW1hbnRpY3MsPC9saT4KICAgICAgPGxpPmd1aWRlbGluZXMgYW5kIG1lY2hhbmlzbXMg Zm9yIGhvc3QgYW5kIHVzZXIgYXV0aGVudGljYXRpb24gYW5kIGNvbmZpZGVudGlhbGl0eSw8L2xp PgogICAgICA8bGk+YW4gYXBwbGljYXRpb24tbGF5ZXIgcHJvdG9jb2wgZm9yIGVzdGFibGlzaGlu ZyB0aGUgdXNlcidzIHByZXNlbmNlLDwvbGk+CiAgICAgIDxsaT5hbiBhcHBsaWNhdGlvbi1sYXll ciBwcm90b2NvbCBmb3IgbW92aW5nIGEgdXNlcidzIHByZXNlbmNlIGZyb20gb25lIGF1dGhvcml0 YXRpdmUgaG9zdCB0byBhbm90aGVyLDwvbGk+CiAgICAgIDxsaT5mb3JtYXQgZGVzY3JpcHRpb25z IGZvciBvYmplY3RzIGFuZCBhdmF0YXJzIGluIHRoZSB2aXJ0dWFsIHdvcmxkLCBhbmQ8L2xpPgog ICAgICA8bGk+YW4gYXBwbGljYXRpb24tbGF5ZXIgcHJvdG9jb2wgZm9yIGlkZW50aWZ5aW5nIGFn ZW50cywgYW5kIHJlcXVlc3RpbmcgaW5mb3JtYXRpb24gYWJvdXQgdGhlbS48L2xpPgogICAgPC9v bD4KCiAgICA8aDE+R29hbHMgYW5kIE1pbGVzdG9uZXM6PC9oMT4KCiAgICA8dWw+CiAgICAgIDxs aT48c3Ryb25nPkRlY2VtYmVyIDIwMDk8L3N0cm9uZz4mbmJzcDsiT0dQOiBSZXF1aXJlbWVudHMg YW5kIEludHJvZHVjdGlvbiIgdG8gdGhlIElFU0cgYXMgYW4gSW5mb3JtYXRpb25hbCBSRkM8L2xp PgoKICAgICAgPGxpPjxzdHJvbmc+RGVjZW1iZXIgMjAwOTwvc3Ryb25nPiZuYnNwOyJPR1AgOiBB YnN0cmFjdCBEeW5hbWljIFN0cnVjdHVyZWQgRGF0YSIgdG8gdGhlIElFU0cgYXMgUHJvcG9zZWQg U3RhbmRhcmQ8L2xpPgogICAgICAKICAgICAgPGxpPjxzdHJvbmc+RGVjZW1iZXIgMjAwOTwvc3Ry b25nPiZuYnNwOyJPR1AgOiBGb3VuZGF0aW9uYWwgQ29uY2VwdHMgYW5kIFJlcXVlc3QtUmVzcG9u c2UgVHJhbnNwb3J0IEJpbmRpbmdzIiB0byB0aGUgSUVTRyBhcyBQcm9wb3NlZCBTdGFuZGFyZDwv bGk+CiAgICAgIAogICAgICA8bGk+PHN0cm9uZz5BcHJpbCAyMDEwPC9zdHJvbmc+Jm5ic3A7Ik9H UCA6IEd1aWRlbGluZXMgZm9yIEhvc3QgQXV0aGVudGljYXRpb24iIHRvIHRoZSBJRVNHIGFzIGFu IEluZm9ybWF0aW9uYWwgUkZDPC9saT4KICAgICAgCiAgICAgIDxsaT48c3Ryb25nPkFwcmlsIDIw MTA8L3N0cm9uZz4mbmJzcDsiT0dQIDogU2VydmljZSBFc3RhYmxpc2htZW50IiB0byB0aGUgSUVT RyBhcyBQcm9wb3NlZCBTdGFuZGFyZDwvbGk+CiAgICAgIAogICAgICA8bGk+PHN0cm9uZz5BcHJp bCAyMDEwPC9zdHJvbmc+Jm5ic3A7Ik9HUCA6IENsaWVudCBBcHBsaWNhdGlvbiBMYXVuY2ggTWVz c2FnZSIgdG8gdGhlIElFU0cgYXMgYW4gSW5mb3JtYXRpb25hbCBSRkM8L2xpPgogICAgICAKICAg ICAgPGxpPjxzdHJvbmc+QXByaWwgMjAxMDwvc3Ryb25nPiZuYnNwOyJPR1AgOiBTaW11bGF0aW9u IFByZXNlbmNlIEVzdGFibGlzaG1lbnQiIHRvIHRoZSBJRVNHIGFzIFByb3Bvc2VkIFN0YW5kYXJk PC9saT4KICAgICAgCiAgICAgIDxsaT48c3Ryb25nPkF1Z3VzdCAyMDEwPC9zdHJvbmc+Jm5ic3A7 Ik9HUCA6IFByaW1pdGl2ZSBPYmplY3QgRm9ybWF0IiB0byB0aGUgSUVTRyBhcyBQcm9wb3NlZCBT dGFuZGFyZDwvbGk+CiAgICAgIAogICAgICA8bGk+PHN0cm9uZz5BdWd1c3QgMjAxMDwvc3Ryb25n PiZuYnNwOyJPR1AgOiBEaWdpdGFsIEFzc2V0IEFjY2VzcyIgdG8gdGhlIElFU0cgYXMgUHJvcG9z ZWQgU3RhbmRhcmQ8L2xpPgogICAgICAKICAgICAgPGxpPjxzdHJvbmc+RGVjZW1iZXIgMjAxMDwv c3Ryb25nPiZuYnNwOyJPR1AgOiBFbnRpdHkgSWRlbnRpZmllcnMiIHRvIHRoZSBJRVNHIGFzIFBy b3Bvc2VkIFN0YW5kYXJkPC9saT4KICAgICAgCiAgICA8L3VsPgogIDwvYm9keT4KPC9odG1sPg== --0016e6476e76cf675e046e0d8170-- From dhc2@dcrocker.net Mon Jul 6 13:05: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 749CB3A657C for ; Mon, 6 Jul 2009 13:05: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=[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 bodDoYQD-CIH for ; Mon, 6 Jul 2009 13:05:26 -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 075E33A6983 for ; Mon, 6 Jul 2009 13:05:25 -0700 (PDT) Received: from [127.0.0.1] (ppp-68-120-199-146.dsl.pltn13.pacbell.net [68.120.199.146]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n66K5fLe024107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Jul 2009 13:05:47 -0700 Message-ID: <4A525917.6090007@dcrocker.net> Date: Mon, 06 Jul 2009 13:05:43 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Infinity Linden References: <3a880e2c0907061116r670f8d19t75afd7f4ab733ae1@mail.gmail.com> In-Reply-To: <3a880e2c0907061116r670f8d19t75afd7f4ab733ae1@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]); Mon, 06 Jul 2009 13:05:47 -0700 (PDT) Cc: ogpx@ietf.org Subject: Re: [ogpx] revised draft charter for OGPX working group 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, 06 Jul 2009 20:05:27 -0000 Infinity Linden wrote: > thanks to the many people who offered suggestions concerning the OGPX > draft charter, we now have a new revision. Hi. A few questions: Although it might be implied from some comments later in the draft, the beginning of the draft charter does not make explicit what value-add is being pursued. That is, What problems will be solved? What will be possible after the work is done that isn't possible now? I'll offer some guesses, but have no faith in my understanding of things: 1. There are multiple VW instances that exist independently and cannot interoperate. This work will permit exchange of virtual objects and (...?) among independent virtual worlds. 2. Currently, a user must have a distinct and unrelated presence in each virtual world that they participate in. This work will permit a user to have a single, unique presence, across multiple VW instances. First, are these two statements correct? Second, will the work solve other problems or create other enhancements? Also: A topic that's been discussed frequently is the difference between having a client able to access multiple servers, versus having independent servers directly interact. From the draft charter, I cannot tell which of these will be covered or how. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From meadhbh.siobhan@gmail.com Mon Jul 6 14:15: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 802483A6DFC for ; Mon, 6 Jul 2009 14:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_00=-2.599, J_BACKHAIR_34=1, J_CHICKENPOX_72=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 0M5etudW1Fs6 for ; Mon, 6 Jul 2009 14:15:26 -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 3CEED3A6DFB for ; Mon, 6 Jul 2009 14:15:26 -0700 (PDT) Received: by gxk26 with SMTP id 26so1253724gxk.13 for ; Mon, 06 Jul 2009 14:14: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 :content-transfer-encoding; bh=kQo+6znxcuBz2dtzAeyQm1pRG2+sjPG0d+b9uUKpVeU=; b=Fh/5FCdG10dVAC6ScjnBpicKDE/7sKDov87DASJznOltreA9EPC9JUyR/zfg+KmN4h Kg8r2WRTmUrFGN22d/cDmRuFe1VquBA75WJb050q69kUmbnHiiQ2X2xSSSe2jzwoAXC7 Z8O4RVXmNslQDBVgqy9GK0NeWBtLcLaTb5r4M= 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=P0GEN9WjVSVg9kiQUmSBObkMtmLhxUiT6s+kOUBOQBXFt7iYTsVZWu+i/FDeGsWi6x XBsKKnqNael1hgz6mvz9iJ04t+pka4zIjihG1wT2QgKGtE++0evXUNn/3BDHP/FZE5Cv bYIBcYpZnB61iX8ZO9cmYiUEqg3T6EWTtSpMU= MIME-Version: 1.0 Received: by 10.100.128.8 with SMTP id a8mr9252696and.121.1246914848338; Mon, 06 Jul 2009 14:14:08 -0700 (PDT) In-Reply-To: <4A525917.6090007@dcrocker.net> References: <3a880e2c0907061116r670f8d19t75afd7f4ab733ae1@mail.gmail.com> <4A525917.6090007@dcrocker.net> Date: Mon, 6 Jul 2009 14:14:08 -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] revised draft charter for OGPX working group 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, 06 Jul 2009 21:15:27 -0000 Dave. we're actually going for a much narrower scope. MMOX was about what you mention, an integrated protocol for _all_ virtual worlds. OGPX is about OGPish systems; drawing on what we learned from two years of interop experiments with "second lifelike" systems such as Second Life(tm), OpenSim(tm?) and arguably realXtend(tm). the statement "The objective of the OGPX working group is to provide an application-layer wire protocol for Virtual Worlds to enable interoperability between applications and provide for access and exchange with other systems on the internet such as web services, e-mail and other information storage systems." describes the objective of the working group and it's value add. right now in the domain of "second lifelike" systems there are a collection of protocols (opensim and SL are very close, realXtend a litter further away, but still pretty close.) the work of OGPX is to get agreement amongst this set of participants. the charter does not detail the architecture of a OGP "compliant" virtual world, but defers to the introduction and requirements draft. and even then, there's some wiggle-room depending on how you want to deploy your services. OGP defines an application layer protocol, it does not mandate your architecture. this is analogous to the way services are deployed for a web application. you could, if you wanted, put the endpoints for your service on a single host ( http://www.example.com/login or http://www.example.com/chat ) or on distinct hosts ( http://login.example.com/ or http://chat.example.com/ .) ultimately it doesn't affect HTTP. that being said, the intro and requirements doc describes a situation where a client application authenticates itself to a single agent domain through which services addresses are resolved. the alternative approach, like what is being used in hypergrid, where the client logs into each service individually could make use of some of the underlying primitives in OGP (capabilities, LLSD / LLIDL, OGP<->HTTP binding, etc.) though it does sort of break the OGP trust model. so... to answer your questions... will this permit transfer of digital assets from one arbitrary virtual world to another? no. digital asset transfers in OGP will be limited from/to OGP compliant worlds; OGP won't let you transfer an object from World of Warcraft(tm) to The Sims Online(tm) using their native protocols. and.. will this work will permit a user to have a single, unique presence, across multiple VW instances? no. you won't be able to login to World of Warcraft(tm) with your Second Life(tm) username and password using their native protocols. what it does allow is for a digital asset access protocol to be defined so you can have a digital assets maintained by a distinct administrative domain and have those assets appear in a virtual world, where the hosts that provide simulation services belong to distinct administrative domains. or... in OGP lingo... a client's agent domain may tell the client it's user's assets "live" on servers operated by a third party. and that user's avatar may rez those assets in a portion of a virtual world being simulated by yet a different third party. ultimately however, OGP is more about mechanism than policy. the OGP draft specs do not disallow a client from connecting to multiple agent domains, but the intent of OGP is that it will define a protocol that provides a meaningful experience with a single agent domain per user account. clear as mud, eh? On Mon, Jul 6, 2009 at 1:05 PM, Dave CROCKER wrote: > > > Infinity Linden wrote: >> >> thanks to the many people who offered suggestions concerning the OGPX >> draft charter, we now have a new revision. > > > Hi. =A0A few questions: > > Although it might be implied from some comments later in the draft, the > beginning of the draft charter does not make explicit what value-add is > being pursued. > > That is, > > =A0 What problems will be solved? > > =A0 What will be possible after the work is done that isn't possible now? > > > I'll offer some guesses, but have no faith in my understanding of things: > > =A0 1. =A0There are multiple VW instances that exist independently and ca= nnot > interoperate. =A0This work will permit exchange of virtual objects and (.= ..?) > among independent virtual worlds. > > =A0 2. =A0Currently, a user must have a distinct and unrelated presence i= n each > virtual world that they participate in. =A0This work will permit a user t= o > have a single, unique presence, across multiple VW instances. > > > First, are these two statements correct? > > Second, will the work solve other problems or create other enhancements? > > Also: =A0A topic that's been discussed frequently is the difference betwe= en > having a client able to access multiple servers, versus having independen= t > servers directly interact. =A0From the draft charter, I cannot tell which= of > these will be covered or how. > > 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 Mon Jul 6 14:20: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 E78613A69BF for ; Mon, 6 Jul 2009 14:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.413, 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 m-sv9ADz-met for ; Mon, 6 Jul 2009 14:20:54 -0700 (PDT) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.210.182]) by core3.amsl.com (Postfix) with ESMTP id EAB983A6A65 for ; Mon, 6 Jul 2009 14:20:52 -0700 (PDT) Received: by yxe12 with SMTP id 12so7003167yxe.29 for ; Mon, 06 Jul 2009 14:19:07 -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=4cx63MoJRx/mUN4p5qJb1zfwFOzj0z7UfLhUH7B0HQE=; b=dfyLXVOfM8wW9ktDPfJCkSYvlxcxmlWxt9UW0W72aBxnHqfaYerxlFhUQ8zW+0x58X TuX+a53e3srjUT5U/ryPcYzVHHMWxe7SU8TGq06Rr+JHKOrepBtOU1m1NG4mJVP19M6E /5dzJhQQxtdXBmqiq28rVDdm40dk/5iEROqLo= 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=TrqwSYZ1/dmBwqM1VfCwLMBGeLn3zgIlCRwHQocyNO5uh8uI90v1r+9Q6SfjbreOi1 qjOyp61Q5VsgbLvitLubH/x+Jr/MIY2Bg+ZylGG8kitZrgVnpJqu5KjkXONT5yp3j5lb UcmgnZGC3WouBKic0jAkEFWjB6ps2Tub8+L58= MIME-Version: 1.0 Received: by 10.100.248.4 with SMTP id v4mr9286167anh.57.1246915147522; Mon, 06 Jul 2009 14:19:07 -0700 (PDT) In-Reply-To: <4A525917.6090007@dcrocker.net> References: <3a880e2c0907061116r670f8d19t75afd7f4ab733ae1@mail.gmail.com> <4A525917.6090007@dcrocker.net> Date: Mon, 6 Jul 2009 14:19:07 -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] revised draft charter for OGPX working group 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, 06 Jul 2009 21:20:56 -0000 personally, i think we're pretty clear about the value add and i would prefer to not have to say "OGPX is not about things that didn't get done in MMOX." but, if you're unclear after reading the draft charter and the intro and requirements draft, chances are other people would be as well. what verbiage would you recommend to make it more clear that OGPX is not MM= OX? -cheers -m On Mon, Jul 6, 2009 at 1:05 PM, Dave CROCKER wrote: > > > Infinity Linden wrote: >> >> thanks to the many people who offered suggestions concerning the OGPX >> draft charter, we now have a new revision. > > > Hi. =A0A few questions: > > Although it might be implied from some comments later in the draft, the > beginning of the draft charter does not make explicit what value-add is > being pursued. > > That is, > > =A0 What problems will be solved? > > =A0 What will be possible after the work is done that isn't possible now? > > > I'll offer some guesses, but have no faith in my understanding of things: > > =A0 1. =A0There are multiple VW instances that exist independently and ca= nnot > interoperate. =A0This work will permit exchange of virtual objects and (.= ..?) > among independent virtual worlds. > > =A0 2. =A0Currently, a user must have a distinct and unrelated presence i= n each > virtual world that they participate in. =A0This work will permit a user t= o > have a single, unique presence, across multiple VW instances. > > > First, are these two statements correct? > > Second, will the work solve other problems or create other enhancements? > > Also: =A0A topic that's been discussed frequently is the difference betwe= en > having a client able to access multiple servers, versus having independen= t > servers directly interact. =A0From the draft charter, I cannot tell which= of > these will be covered or how. > > d/ > -- > > =A0Dave Crocker > =A0Brandenburg InternetWorking > =A0bbiw.net > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From barryleiba.mailing.lists@gmail.com Mon Jul 6 15:58: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 C23DA3A6DC1 for ; Mon, 6 Jul 2009 15:58:40 -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 rChbz+LPjKfR for ; Mon, 6 Jul 2009 15:58:40 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id D155D3A6CD0 for ; Mon, 6 Jul 2009 15:58:39 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so1276911fgg.18 for ; Mon, 06 Jul 2009 15:58:05 -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:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=uhJtnhQpl0Nb9YadCAhBWsbjfvS1psKYXAF8zN4m3nY=; b=K8y0E8gV14wCRkwvVdTfu0nOHCCIgTNFIDSJaa+lu9b0idV48AOUnOEEh1eu6YfzDk ZCOp18jX3vlurmV91uX8JsjHtiQ73rBhXky0lGb1y01Yd5DQ/VLs5fgHvvlC4wVuMBiP XeEGl2i1t+NObjJVjjwvxmTExaW10JCg9J4Tw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=rJUHuGYw18YTVdTsYamXkRV8BNhZL1NDGeAcv0tm34QdNkHXyg2NMX1//VHzlJS/Yt PPHernujVxhy7XMePDZxGVOxnL1bHMC5ZAgDIEzqwSrcmdYqjZN4To0rg7xH4/EMp9rt BMlpHngFeHB41NALGgm5TMmKHZnrkhx7vUab4= MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.239.137.69 with SMTP id k5mr436275hbk.111.1246920629113; Mon, 06 Jul 2009 15:50:29 -0700 (PDT) In-Reply-To: References: <3a880e2c0907061116r670f8d19t75afd7f4ab733ae1@mail.gmail.com> <4A525917.6090007@dcrocker.net> Date: Mon, 6 Jul 2009 18:50:29 -0400 X-Google-Sender-Auth: ae5b0f477559f578 Message-ID: <6c9fcc2a0907061550t435c7552wbc24bcf0d874e792@mail.gmail.com> From: Barry Leiba To: ogpx@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dcrocker@bbiw.net Subject: Re: [ogpx] revised draft charter for OGPX working group 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, 06 Jul 2009 22:58:40 -0000 > personally, i think we're pretty clear about the value add and i would > prefer to not have to say "OGPX is not about things that didn't get > done in MMOX." > > but, if you're unclear after reading the draft charter and the intro > and requirements draft, chances are other people would be as well. > > what verbiage would you recommend to make it more clear that OGPX is not MMOX? Indeed; what Meadhbh said. As one of the BOF chairs, I'll say that I'm happy with the charter now, after some side-bashing we had (the chairs and the ADs). The dates for the work items are unrealistic, but we'll sort them out when we're at the stage of finalizing the charter. So at this point, if you have a better understanding of the goals and have specific text to suggest, that'd be wonderful. Though, please, not "verbiage"[1]; concise wording that's to the point would be best. Barry Leiba, ODPX BOF co-chair [1] "You keep using that word. I do not think it means what you think it means. " -- Inigo Montoya From belxjander@gmail.com Thu Jul 9 02:45: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 09ECE3A6C8B for ; Thu, 9 Jul 2009 02:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 W-hlI2XSr417 for ; Thu, 9 Jul 2009 02:45:12 -0700 (PDT) Received: from mail-px0-f201.google.com (mail-px0-f201.google.com [209.85.216.201]) by core3.amsl.com (Postfix) with ESMTP id 0F8FF3A6C83 for ; Thu, 9 Jul 2009 02:45:11 -0700 (PDT) Received: by pxi39 with SMTP id 39so5115pxi.29 for ; Thu, 09 Jul 2009 02:45:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:disposition-notification-to:content-type :date:message-id:mime-version:x-mailer:content-transfer-encoding; bh=0MDdv1+dpnwCkNBCxX3JT3h3oyphfsuBFelJJhfIQgo=; b=eLawdzocC4R3Up7yfltiDv4LpwNbbhwj2UJzgbhUaYRb12id9O9fP58MN9jBZ2qVL6 atjsqFEhifPJv1U9xTZIdlWzBR2MA9f0M3FTR3CJfWQT8GOg8boz1yF1mPL5jjlik5LB RcoFm7aGqKJ5KBTgvaCeUlYL1ptU8s9eGULBw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references :disposition-notification-to:content-type:date:message-id :mime-version:x-mailer:content-transfer-encoding; b=ZthaX3+Zg4lEuReEHvkV8qZmA2MJlrtr6BtJFXtL+Pkqz9ink4Ari0exa36WeSNyDS eu0tPJSW5sjbhSzTryjlUuvVX+VRqmI4oGD4FflOtmJx1a0GpKgqv53in8DhEehY64xQ R11WOI5BGqJWXv5xYyJuMXuUZ3YFAcENTDC3w= Received: by 10.114.154.12 with SMTP id b12mr985042wae.22.1247132737542; Thu, 09 Jul 2009 02:45:37 -0700 (PDT) Received: from ?10.2.1.3? (p3146-ipbfp203tottori.tottori.ocn.ne.jp [123.226.140.146]) by mx.google.com with ESMTPS id m34sm16853648waf.22.2009.07.09.02.45.34 (version=SSLv3 cipher=RC4-MD5); Thu, 09 Jul 2009 02:45:35 -0700 (PDT) From: Kajikawa Jeremy To: Charles Krinke In-Reply-To: <897153.73396.qm@web82601.mail.mud.yahoo.com> References: <3a880e2c0906280906i2cdcdaa3m3c1b1ef54e4e5fcb@mail.gmail.com> <20090629105140.GA1053@alinoe.com> <20090629114512.GC1053@alinoe.com> <20090629161121.GA17251@alinoe.com> <20090629161815.GB17251@alinoe.com> <591737.89462.qm@web82608.mail.mud.yahoo.com> <3a880e2c0906291219t1990272fkb276979ebc97d292@mail.gmail.com> <897153.73396.qm@web82601.mail.mud.yahoo.com> Content-Type: text/plain Date: Thu, 09 Jul 2009 16:48:14 +0900 Message-Id: <1247125694.11996.31.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.26.2 Content-Transfer-Encoding: 7bit Cc: Infinity Linden , Meadhbh Siobhan , ogpx@ietf.org Subject: Re: [ogpx] A Review of Multi-Domain Use Cases [Was: Re: OpenID and OGP : beginning the discussion ...] 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, 09 Jul 2009 09:45:13 -0000 Are the UUIDs given on any individual instance (region domain/agent domain) exposable across to another domain ? It appears that you would need a @ arrangement... specifically recognising Avatar UUIDs as @local and using an @ when exposed as being from a remote grid ("GridID/GridString" simply naming a connection handle?) potentialy useful or am I getting hung up on details? On Mon, 2009-06-29 at 12:25 -0700, Charles Krinke wrote: > Hmmm. Well, it seems reasonable to me that each grid has one and only > one first/last avatar of any particular first and last. > > Admiteddly, I am more focused on the OpenSim and the OSGrid side of > this interop discussion, but, since the precedent has already been set > for .@GridName.Com it seems a reasonable and > non-ambiguous method. > > All avatars on OpenSim grids do have a UUID, so that could certainly > be exposed. Then we could have conversations between > "0123-4567-89ab-123456899abc-defa" and others instead of > .@gridname.com, I suppose. > > Charles Krinke > > > > ______________________________________________________________________ > From: Infinity Linden > To: Charles Krinke > Cc: Carlo Wood ; Meadhbh Siobhan > ; ogpx@ietf.org > Sent: Monday, June 29, 2009 12:19:18 PM > Subject: Re: [ogpx] A Review of Multi-Domain Use Cases [Was: Re: > OpenID and OGP : beginning the discussion ...] > > hmm... i think over in the OGP world we have a history of being > enamored with capabilities and RESTful resources, ergo my suggestion > that an agent's unique ID be an URL. If the public URL a service may > go to to get public information about an agent is the unique ID for an > avatar, then you don't need a name to service resolution step, which > has some advantages. i don't want to sound partisan, but the > formulation below (that looks like an email address) seems to have the > potential for ambiguity. > > On Mon, Jun 29, 2009 at 11:11 AM, Charles Krinke > wrote: > > In some interop scenarios, and I am using HyperGrid as an example as > it > > addresses the same problem, the current solution is to use: > > > > .@GridName.Com > > > > Which is not an email, but is a unique identifier for an avatar on a > > particular grid. > > > > As OGP moves forward, it seems reasonable to me that the Grids (or > perhaps > > AgentDomains to use the vernacular here) are the authority for a > particular > > avatar that comes from that grid. > > > > Charles Krinke > > > > ________________________________ > > From: Carlo Wood > > To: Meadhbh Siobhan > > Cc: Infinity Linden ; ogpx@ietf.org > > Sent: Monday, June 29, 2009 9:18:15 AM > > Subject: Re: [ogpx] A Review of Multi-Domain Use Cases [Was: Re: > OpenID and > > OGP : beginning the discussion ...] > > > > On Mon, Jun 29, 2009 at 06:11:21PM +0200, Carlo Wood wrote: > >> If this is the case, then I'm happy and there should be no problems > >> in the future regarding this. If no separate ID is provided then > >> several problems occur: > >> * Impersonation (people deliberately using the same shape and skin > etc) > >> * IM's will be logged to the same file, because the viewer can't > >> know who is who. > >> > >> Also, the ID has to be same every time - because the viewer will > >> need to recognize that this John Smith is not AGAIN a new one, > >> but the same, every time. > > > > To clarify; what started this thread was this: > > > > & identifier = { > > type: 'agent', > > first_name: string, > > last_name: string, > > } > > > > Here I only see 'first_name' and 'last_name'. > > As we've established now (I hope) this is not enough at > > any level of the protocol, not between servers, but also > > not between server and client. > > > > Hence, it worried me. If you say "identifier" I expect > > something globally unique. > > > > I think this should be: > > > > & identifier = { > > type: 'agent', > > uuid: string, > > first_name: string, > > last_name: string, > > } > > > > Where the uuid is not only unique, but constant for any given > > account (it doesn't change if one logs out and logs in again). > > It could be an email address, but for privacy reasons I think > > that should not be used; some hash seems much more logical. > > > > -- > > 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 alexey.melnikov@isode.com Tue Jul 14 11:52: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 BE5113A6ABB for ; Tue, 14 Jul 2009 11:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.784 X-Spam-Level: X-Spam-Status: No, score=-2.784 tagged_above=-999 required=5 tests=[AWL=-0.185, 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 R-RFS3Fw8DsQ for ; Tue, 14 Jul 2009 11:52:51 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id F1BCB3A6AF4 for ; Tue, 14 Jul 2009 11:52:50 -0700 (PDT) Received: from [94.197.215.214] (94.197.215.214.threembb.co.uk [94.197.215.214]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 14 Jul 2009 19:52:43 +0100 Message-ID: <4A5CD3D0.4040309@isode.com> Date: Tue, 14 Jul 2009 19:52:00 +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: ogpx@ietf.org References: <4A3BE302.5070405@isode.com> In-Reply-To: <4A3BE302.5070405@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ogpx] Greetings from the Area Director sponsoring the OGPX BOF 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, 14 Jul 2009 18:52:51 -0000 Alexey Melnikov wrote: > Greetings, > As you already heard from Meadhbh, the OGPX BOF in Stockholm was > approved. > I am quite excited about this and I very much hope that it goes well, > so that a new Working Group can be formed after Stockholm. > > I will be announcing the BOF chairs soon. I trust them to make sure > that the BOF is a success. And I forgot to announce them publicly. Sorry about that. The BOF chairs are Jon Peterson and Barry Leiba From infinity@lindenlab.com Tue Jul 14 13:00: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 CC87F3A689E for ; Tue, 14 Jul 2009 13:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.833 X-Spam-Level: X-Spam-Status: No, score=-0.833 tagged_above=-999 required=5 tests=[AWL=-0.715, 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 WZGu1OAASXSE for ; Tue, 14 Jul 2009 13:00:39 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by core3.amsl.com (Postfix) with ESMTP id DF8103A6868 for ; Tue, 14 Jul 2009 13:00:38 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c37so1464373anc.4 for ; Tue, 14 Jul 2009 12:56:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.108.8 with SMTP id g8mr9223696anc.66.1247601067666; Tue, 14 Jul 2009 12:51:07 -0700 (PDT) Date: Tue, 14 Jul 2009 12:51:07 -0700 Message-ID: <3a880e2c0907141251u18ca796dr69f7ec077f043be0@mail.gmail.com> From: Infinity Linden To: ogpx@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [ogpx] current OGP related drafts 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, 14 Jul 2009 20:00:39 -0000 hey everybody, in preparation for the upcoming BoF, i updated the list of drafts related to OGP at https://wiki.secondlife.com/wiki/User:Infinity_Linden/IETF_Drafts_and_Meetings . it's an unofficial list, but i believe it's correct. if there are more drafts that should be on this list, lemme know. -cheers -meadhbh From infinity@lindenlab.com Tue Jul 14 13:07: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 C0CF23A6868 for ; Tue, 14 Jul 2009 13:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[AWL=0.238, 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 bvYNMT0ekJPy for ; Tue, 14 Jul 2009 13:07:35 -0700 (PDT) Received: from mail-yx0-f196.google.com (mail-yx0-f196.google.com [209.85.210.196]) by core3.amsl.com (Postfix) with ESMTP id 016423A6826 for ; Tue, 14 Jul 2009 13:07:34 -0700 (PDT) Received: by yxe34 with SMTP id 34so3416691yxe.29 for ; Tue, 14 Jul 2009 13:04:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.164.20 with SMTP id m20mr9055921ane.31.1247601890678; Tue, 14 Jul 2009 13:04:50 -0700 (PDT) Date: Tue, 14 Jul 2009 13:04:50 -0700 Message-ID: <3a880e2c0907141304x71ab5947nb61fac77bcbc52ce@mail.gmail.com> From: Infinity Linden To: ogpx@ietf.org Content-Type: multipart/mixed; boundary=0016e643461283d737046eaff36a Subject: [ogpx] Revised Draft Charter for Proposed OGPX Working Group 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, 14 Jul 2009 20:07:35 -0000 --0016e643461283d737046eaff36a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi everybody, we recently received a request to add an explicit link to an informational resource in the wg charter. the concern is that some terminology in the charter may go unexplained. enclosed is the latest consensus charter with a link to the Introduction and Requirements draft. cheers! meadhbh --0016e643461283d737046eaff36a Content-Type: application/xhtml+xml; name="ogpx-draft-charter.xhtml" Content-Disposition: attachment; filename="ogpx-draft-charter.xhtml" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fx51x5vq0 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPCFET0NUWVBFIGh0bWwgUFVC TElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgU3RyaWN0Ly9FTiIKICAgICAgICAgICAgICAgICAg ICAgICJodHRwOi8vd3d3LnczLm9yZy9UUi94aHRtbDEvRFREL3hodG1sMS1zdHJpY3QuZHRkIj4K PGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGh0bWwiPgogIDxoZWFkPgogICAg PHRpdGxlPk9HUFggV29ya2luZyBHcm91cCBEcmFmdCBDaGFydGVyPC90aXRsZT4KICA8L2hlYWQ+ CiAgPGJvZHk+CiAgICA8aDE+V29ya2luZyBHcm91cCBOYW1lOjwvaDE+CiAgICA8cD5PcGVuIEdy aWQgUHJvdG9jb2wgKE9HUFgpPC9wPgoKICAgIDxoMT5DaGFpcnM6PC9oMT4KICAgIDxwPlRCRDwv cD4KCiAgICA8aDE+QXJlYSBhbmQgQXJlYSBEaXJlY3RvcnM6PC9oMT4KICAgIDxwPkFwcGxpY2F0 aW9ucyBBcmVhPC9wPgogICAgPHA+TGlzYSBEdXNzZWF1bHQgJmx0O2xpc2EuZHVzc2VhdWx0QG1l c3NhZ2luZ2FyY2hpdGVjdHMuY29tJmd0OzwvcD4KICAgIDxwPkFsZXhleSBNZWxuaWtvdiAmbHQ7 YWxleGV5Lm1lbG5pa292QGlzb2RlLmNvbSZndDs8L3A+CgogICAgPGgxPlJlc3BvbnNpYmxlIEFy ZWEgRGlyZWN0b3I6PC9oMT4KICAgIDxwPlRCRDwvcD4KCiAgICA8aDE+TWFpbGluZyBMaXN0Ojwv aDE+CiAgICA8cD4KICAgIG9ncHhAaWV0Zi5vcmcKICAgIDxiciAvPgogICAgaHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29ncHgKICAgIDwvcD4KCiAgICA8aDE+RGVzY3JpcHRp b24gb2YgV29ya2luZyBHcm91cDo8L2gxPgoKICAgIDxwPlZpcnR1YWwgV29ybGRzIChWV3MpIGFu ZCBvdGhlciBNYXNzaXZlbHkgTXVsdGktUGFydHkgT25saW5lCiAgICAgIEFwcGxpY2F0aW9ucyAo TU1PcykgYXJlIG9mIGluY3JlYXNpbmcgaW50ZXJlc3QgdG8gdGhlIEludGVybmV0CiAgICAgIGNv bW11bml0eS4gSW5udW1lcmFibGUgZXhhbXBsZXMgZXhpc3Qgb2Ygc3VjaCBhcHBsaWNhdGlvbnMs IG1vc3QKICAgICAgdXNpbmcgcHJvcHJpZXRhcnkgcHJvdG9jb2xzLiBXaXRoIHRoZWlyIHJvb3Rz IGluIGdhbWVzIGFuZCBzb2NpYWwKICAgICAgaW50ZXJhY3Rpb24sIFZpcnR1YWwgV29ybGRzIGFy ZSBub3cgYmVpbmcgdXNlZCBpbmNyZWFzaW5nbHkgaW4KICAgICAgYnVzaW5lc3MsIGVkdWNhdGlv biBhbmQgaW5mb3JtYXRpb24gZXhjaGFuZ2UuIFdpdGggYSBncm93aW5nIHVzZXIKICAgICAgYmFz ZSwgY3JlYXRvcnMgb2Ygc3VjaCBzeXN0ZW1zIGFyZSBpbnRlcmVzdGVkIGluIGRldmVsb3Bpbmcg YQogICAgICBzdGFuZGFyZCB2aXJ0dWFsIHdvcmxkcyBwcm90b2NvbCB0byBlbmFibGUgaW50ZXJv cGVyYWJpbGl0eS48L3A+CgogICAgPHA+VGhlIG9iamVjdGl2ZSBvZiB0aGUgT0dQWCB3b3JraW5n IGdyb3VwIGlzIHRvIHByb3ZpZGUgYW4KICAgICAgYXBwbGljYXRpb24tbGF5ZXIgd2lyZSBwcm90 b2NvbCBmb3IgVmlydHVhbCBXb3JsZHMgdG8gZW5hYmxlCiAgICAgIGludGVyb3BlcmFiaWxpdHkg YmV0d2VlbiBhcHBsaWNhdGlvbnMgYW5kIHByb3ZpZGUgZm9yIGFjY2VzcyBhbmQKICAgICAgZXhj aGFuZ2Ugd2l0aCBvdGhlciBzeXN0ZW1zIG9uIHRoZSBpbnRlcm5ldCBzdWNoIGFzIHdlYiBzZXJ2 aWNlcywKICAgICAgZS1tYWlsIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzdG9yYWdlIHN5c3RlbXMu IFRoZSBPcGVuIEdyaWQgUHJvdG9jb2wKICAgICAgKE9HUCkgd2lsbCBkZXNjcmliZSBzZW1hbnRp Y3MgYW5kIHByb3RvY29sIGludGVyYWN0aW9uIGZvciB0aGUKICAgICAgdmlydHVhbCB3b3JsZCwg aW5kZXBlbmRlbnQgb2YgdHJhbnNwb3J0LCB0aG91Z2ggYmluZGluZ3MgZm9yCiAgICAgIGNhcnJ5 aW5nIE9HUCBvdmVyIEhUVFAgd2lsbCBiZSBkZWZpbmVkLjwvcD4KCiAgICA8cD5UaGUgY29yZSB3 b3JrIG9mIHRoZSBncm91cCB3aWxsIGJlIHRoZSBwcm9kdWN0aW9uIG9mIHRoZSBPcGVuCiAgICAg IEdyaWQgUHJvdG9jb2wgc3VpdGUgKE9HUCksIGEgc2V0IG9mIGFwcGxpY2F0aW9uIHByb3RvY29s cyB0bwogICAgICBjb21tdW5pY2F0ZSBhbmQgaW50ZXJhY3Qgd2l0aCB0aGUgc3RhdGUgb2YgVmly dHVhbCBXb3JsZAogICAgICBhcHBsaWNhdGlvbnMuIFRoZSBPcGVuIEdyaWQgUHJvdG9jb2wgd2ls bCBkZWZpbmUgdmlydHVhbCB3b3JsZHMgd2l0aAogICAgICB0aGUgZm9sbG93aW5nIGFzc3VtcHRp b25zOjwvcD4KCiAgICA8dWw+CiAgICAgIDxsaT5UaGUgVmlydHVhbCBXb3JsZCBleGlzdHMgaW5k ZXBlbmRlbnQgb2YgdGhlIHBhcnRpY2lwYXRpbmcgY2xpZW50cy48L2xpPgogICAgICA8bGk+VXNl cnMgaGF2ZSBhIHNpbmdsZSwgdW5pcXVlIHByZXNlbmNlIGluIHRoZSB2aXJ0dWFsIHdvcmxkLjwv bGk+CiAgICAgIDxsaT5UaGUgdmlydHVhbCB3b3JsZCBjb250YWlucyBwZXJzaXN0ZW50IG9iamVj dHMuPC9saT4KICAgICAgPGxpPlRoZSB2aXJ0dWFsIHdvcmxkIG1heSBiZSBwYXJ0aXRpb25lZC48 L2xpPgogICAgICA8bGk+UHJlc2VuY2UsIHN0YXRlIGFuZCBzaW11bGF0aW9uIG9jY3VyIG9uIGF1 dGhvcml0YXRpdmUgaG9zdHMuPC9saT4KICAgIDwvdWw+CiAgICAKICAgIDxwPkZ1cnRoZXIgZGV0 YWlscyByZWdhcmRpbmcgdGhlIHN0cnVjdHVyZSBvZiBhbmQgcmVxdWlyZW1lbnRzIGZvciB2aXJ0 dWFsCiAgICAgIHdvcmxkcyBkZXNjcmliZWQgYnkgdGhpcyBncm91cCBtYXkgYmUgZm91bmQgYXQg dGhlIGRvY3VtZW50CiAgICAgIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWhhbXJpY2stb2dwLWludHJvLTAwIj5PcGVuCiAgICAgIEdyaWQgUHJvdG9jb2wgOiBJbnRy b2R1Y3Rpb24gYW5kIFJlcXVpcmVtZW50czwvYT48L3A+CiAgICAKICAgIDxwPkZvdW5kYXRpb25h bCBjb21wb25lbnRzIG9mIHRoZSBPcGVuIEdyaWQgUHJvdG9jb2wgaW5jbHVkZSB0aGUgcHVibGlj YXRpb24gb2Y8L3A+CiAgICAKICAgIDxvbD4KICAgICAgPGxpPmFuIGFic3RyYWN0IGR5bmFtaWMg c3RydWN0dXJlZCBkYXRhIHN5c3RlbSwgc3VpdGFibGUgZm9yIGRlc2NyaWJpbmcgdGhlIGFwcGxp Y2F0aW9uIHByb3RvY29sIGluIGEgdHJhbnNwb3J0LW5ldXRyYWwgbWFubmVyLDwvbGk+CiAgICAg IDxsaT5jbGVhciBzZW1hbnRpY3MgYW5kIG1lY2hhbmlzbXMgZm9yIGNhcnJ5aW5nIE9HUCBtZXNz YWdlcyBvdmVyIG1lc3NhZ2Utb3JpZW50ZWQgdHJhbnNwb3J0cyB3aXRoIHJlcXVlc3QvcmVzcG9u c2Ugc2VtYW50aWNzLDwvbGk+CiAgICAgIDxsaT5ndWlkZWxpbmVzIGFuZCBtZWNoYW5pc21zIGZv ciBob3N0IGFuZCB1c2VyIGF1dGhlbnRpY2F0aW9uIGFuZCBjb25maWRlbnRpYWxpdHksPC9saT4K ICAgICAgPGxpPmFuIGFwcGxpY2F0aW9uLWxheWVyIHByb3RvY29sIGZvciBlc3RhYmxpc2hpbmcg dGhlIHVzZXIncyBwcmVzZW5jZSw8L2xpPgogICAgICA8bGk+YW4gYXBwbGljYXRpb24tbGF5ZXIg cHJvdG9jb2wgZm9yIG1vdmluZyBhIHVzZXIncyBwcmVzZW5jZSBmcm9tIG9uZSBhdXRob3JpdGF0 aXZlIGhvc3QgdG8gYW5vdGhlciw8L2xpPgogICAgICA8bGk+Zm9ybWF0IGRlc2NyaXB0aW9ucyBm b3Igb2JqZWN0cyBhbmQgYXZhdGFycyBpbiB0aGUgdmlydHVhbCB3b3JsZCwgYW5kPC9saT4KICAg ICAgPGxpPmFuIGFwcGxpY2F0aW9uLWxheWVyIHByb3RvY29sIGZvciBpZGVudGlmeWluZyBhZ2Vu dHMsIGFuZCByZXF1ZXN0aW5nIGluZm9ybWF0aW9uIGFib3V0IHRoZW0uPC9saT4KICAgIDwvb2w+ CgogICAgPGgxPkdvYWxzIGFuZCBNaWxlc3RvbmVzOjwvaDE+CgogICAgPHVsPgogICAgICA8bGk+ PHN0cm9uZz5EZWNlbWJlciAyMDA5PC9zdHJvbmc+Jm5ic3A7Ik9HUDogUmVxdWlyZW1lbnRzIGFu ZCBJbnRyb2R1Y3Rpb24iIHRvIHRoZSBJRVNHIGFzIGFuIEluZm9ybWF0aW9uYWwgUkZDPC9saT4K CiAgICAgIDxsaT48c3Ryb25nPkRlY2VtYmVyIDIwMDk8L3N0cm9uZz4mbmJzcDsiT0dQIDogQWJz dHJhY3QgRHluYW1pYyBTdHJ1Y3R1cmVkIERhdGEiIHRvIHRoZSBJRVNHIGFzIFByb3Bvc2VkIFN0 YW5kYXJkPC9saT4KICAgICAgCiAgICAgIDxsaT48c3Ryb25nPkRlY2VtYmVyIDIwMDk8L3N0cm9u Zz4mbmJzcDsiT0dQIDogRm91bmRhdGlvbmFsIENvbmNlcHRzIGFuZCBSZXF1ZXN0LVJlc3BvbnNl IFRyYW5zcG9ydCBCaW5kaW5ncyIgdG8gdGhlIElFU0cgYXMgUHJvcG9zZWQgU3RhbmRhcmQ8L2xp PgogICAgICAKICAgICAgPGxpPjxzdHJvbmc+QXByaWwgMjAxMDwvc3Ryb25nPiZuYnNwOyJPR1Ag OiBHdWlkZWxpbmVzIGZvciBIb3N0IEF1dGhlbnRpY2F0aW9uIiB0byB0aGUgSUVTRyBhcyBhbiBJ bmZvcm1hdGlvbmFsIFJGQzwvbGk+CiAgICAgIAogICAgICA8bGk+PHN0cm9uZz5BcHJpbCAyMDEw PC9zdHJvbmc+Jm5ic3A7Ik9HUCA6IFNlcnZpY2UgRXN0YWJsaXNobWVudCIgdG8gdGhlIElFU0cg YXMgUHJvcG9zZWQgU3RhbmRhcmQ8L2xpPgogICAgICAKICAgICAgPGxpPjxzdHJvbmc+QXByaWwg MjAxMDwvc3Ryb25nPiZuYnNwOyJPR1AgOiBDbGllbnQgQXBwbGljYXRpb24gTGF1bmNoIE1lc3Nh Z2UiIHRvIHRoZSBJRVNHIGFzIGFuIEluZm9ybWF0aW9uYWwgUkZDPC9saT4KICAgICAgCiAgICAg IDxsaT48c3Ryb25nPkFwcmlsIDIwMTA8L3N0cm9uZz4mbmJzcDsiT0dQIDogU2ltdWxhdGlvbiBQ cmVzZW5jZSBFc3RhYmxpc2htZW50IiB0byB0aGUgSUVTRyBhcyBQcm9wb3NlZCBTdGFuZGFyZDwv bGk+CiAgICAgIAogICAgICA8bGk+PHN0cm9uZz5BdWd1c3QgMjAxMDwvc3Ryb25nPiZuYnNwOyJP R1AgOiBQcmltaXRpdmUgT2JqZWN0IEZvcm1hdCIgdG8gdGhlIElFU0cgYXMgUHJvcG9zZWQgU3Rh bmRhcmQ8L2xpPgogICAgICAKICAgICAgPGxpPjxzdHJvbmc+QXVndXN0IDIwMTA8L3N0cm9uZz4m bmJzcDsiT0dQIDogRGlnaXRhbCBBc3NldCBBY2Nlc3MiIHRvIHRoZSBJRVNHIGFzIFByb3Bvc2Vk IFN0YW5kYXJkPC9saT4KICAgICAgCiAgICAgIDxsaT48c3Ryb25nPkRlY2VtYmVyIDIwMTA8L3N0 cm9uZz4mbmJzcDsiT0dQIDogRW50aXR5IElkZW50aWZpZXJzIiB0byB0aGUgSUVTRyBhcyBQcm9w b3NlZCBTdGFuZGFyZDwvbGk+CiAgICAgIAogICAgPC91bD4KICA8L2JvZHk+CjwvaHRtbD4= --0016e643461283d737046eaff36a-- From alexey.melnikov@isode.com Sat Jul 18 04:02: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 4B26E28C2F0 for ; Sat, 18 Jul 2009 04:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 ALbZONYzrHkw for ; Sat, 18 Jul 2009 04:02:31 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id BED0828C331 for ; Sat, 18 Jul 2009 03:58:42 -0700 (PDT) Received: from [92.40.107.114] (92.40.107.114.sub.mbb.three.co.uk [92.40.107.114]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 18 Jul 2009 11:58:40 +0100 Message-ID: <4A61AAB3.8050405@isode.com> Date: Sat, 18 Jul 2009 11:57:55 +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: dcrocker@bbiw.net References: <3a880e2c0907061116r670f8d19t75afd7f4ab733ae1@mail.gmail.com> <4A525917.6090007@dcrocker.net> In-Reply-To: <4A525917.6090007@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Infinity Linden , ogpx@ietf.org Subject: Re: [ogpx] revised draft charter for OGPX working group 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, 18 Jul 2009 11:02:32 -0000 Hi Dave, Dave CROCKER wrote: > Also: A topic that's been discussed frequently is the difference > between having a client able to access multiple servers, versus having > independent servers directly interact. From the draft charter, I > cannot tell which of these will be covered or how. I think this is an important question. There are 3 groups of entities involved in OGP and the charter doesn't make this clear. From belxjander@gmail.com Sat Jul 18 04:19: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 68FF73A6B73 for ; Sat, 18 Jul 2009 04:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 VvVyvl-wizPI for ; Sat, 18 Jul 2009 04:19:45 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by core3.amsl.com (Postfix) with ESMTP id A79743A67DD for ; Sat, 18 Jul 2009 04:19:45 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id f9so313163rvb.49 for ; Sat, 18 Jul 2009 04:19:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:disposition-notification-to:content-type:date:message-id :mime-version:x-mailer:content-transfer-encoding; bh=+SDSIFHyEmdwWGmmbUln6j8nAML27Q4grM+BZP33NoE=; b=j5OK/wtpahORIAdly4/UNiD+Ip7vCdl3bTOr+myN0xRB9ztoUP/iHVMn0BGhsC0Ojp oNeKdsvbGaStTEXp5b2F1R5BPMK8SJhs+ZrZZWOZQRD5blBREMAiSLYUX0b73WP8IhoH 5MneQ7GNeayhckjcRbvVwiryr7fKJCOfm1IqQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:disposition-notification-to :content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; b=nBjhIkTEzKV8gAcH4eXS9BOV/O/fvocUZzIBjswJMyE31ff11rVSvG+BoQHbiBwTSn SvC1HvIq5s5ado9E3Zu6h5GkxGMH5syAtq6WM8QBGPvxyumocCECvphvnwsgfEHltzmZ ou/Ehcrgms0ESXCNlCUA8fl1RnAcLzPIsZ9Us= Received: by 10.140.207.18 with SMTP id e18mr1327060rvg.249.1247915977386; Sat, 18 Jul 2009 04:19:37 -0700 (PDT) Received: from ?10.2.1.3? (p7169-ipbfp401tottori.tottori.ocn.ne.jp [118.13.19.169]) by mx.google.com with ESMTPS id g14sm12079960rvb.24.2009.07.18.04.19.34 (version=SSLv3 cipher=RC4-MD5); Sat, 18 Jul 2009 04:19:36 -0700 (PDT) From: Kajikawa Jeremy To: ogpx@ietf.org In-Reply-To: <4A61AAB3.8050405@isode.com> References: <3a880e2c0907061116r670f8d19t75afd7f4ab733ae1@mail.gmail.com> <4A525917.6090007@dcrocker.net> <4A61AAB3.8050405@isode.com> Content-Type: text/plain Date: Sat, 18 Jul 2009 18:22:53 +0900 Message-Id: <1247908974.10607.2.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.26.2 Content-Transfer-Encoding: 7bit Subject: Re: [ogpx] revised draft charter for OGPX working group 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, 18 Jul 2009 11:19:46 -0000 Well a sketch I recently worked up has AgentDomain and RegionDomain these can be instanced... but both need "SI" or Service Interfaces basically abstracting U G A I M into classes for re-use and standardizing the protocol chatter On Sat, 2009-07-18 at 11:57 +0100, Alexey Melnikov wrote: > Hi Dave, > > Dave CROCKER wrote: > > > Also: A topic that's been discussed frequently is the difference > > between having a client able to access multiple servers, versus having > > independent servers directly interact. From the draft charter, I > > cannot tell which of these will be covered or how. > > I think this is an important question. There are 3 groups of entities > involved in OGP and the charter doesn't make this clear. > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx From dwl@us.ibm.com Sat Jul 18 07:43:18 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 730733A696B; Sat, 18 Jul 2009 07:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 30gEA7J2x25b; Sat, 18 Jul 2009 07:43:16 -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 6E3DC3A69C4; Sat, 18 Jul 2009 07:43:12 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n6IEbS3q002743; Sat, 18 Jul 2009 10:37:28 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n6IEgZ9K257902; Sat, 18 Jul 2009 10:42:35 -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 n6IEgY5b016010; Sat, 18 Jul 2009 10:42:34 -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 n6IEgYEw016005; Sat, 18 Jul 2009 10:42:34 -0400 In-Reply-To: <1247908974.10607.2.camel@localhost> References: <3a880e2c0907061116r670f8d19t75afd7f4ab733ae1@mail.gmail.com> <4A525917.6090007@dcrocker.net> <4A61AAB3.8050405@isode.com> <1247908974.10607.2.camel@localhost> To: Kajikawa Jeremy MIME-Version: 1.0 X-KeepSent: BF6BF0F3:8FE4009B-852575F7:00502DD2; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Sat, 18 Jul 2009 10:42:33 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5|December 05, 2008) at 07/18/2009 10:42:33, Serialize complete at 07/18/2009 10:42:33 Content-Type: multipart/alternative; boundary="=_alternative 0050CD29852575F7_=" Cc: ogpx-bounces@ietf.org, ogpx@ietf.org Subject: Re: [ogpx] revised draft charter for OGPX working group 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, 18 Jul 2009 14:43:18 -0000 This is a multipart message in MIME format. --=_alternative 0050CD29852575F7_= Content-Type: text/plain; charset="US-ASCII" If you look at: http://www.ietf.org/id/draft-levine-ogp-layering-00.txt It begins to address this at the requirements and design pattern level. I'd strongly argue, that if its not clear that we want to permit the protocols to work properly in *all* of those deployments patterns, we need to update the charter to make that clear. My personal perspective is that the OGPX specifications are going to end up defining several hundred "REST" and "RESTish" resources/services, and that grouping and we need to describe how to group and deploy them as deployers see fit. There re some natural clusterings which will be very hard to decouple, but, beyond those, the specifications should strive to give deployers and implementers as much flexibility as possible. - David W. Levine ~ Zha Ewry, In Second Life Kajikawa Jeremy Sent by: ogpx-bounces@ietf.org 07/18/2009 05:22 AM To ogpx@ietf.org cc Subject Re: [ogpx] revised draft charter for OGPX working group Well a sketch I recently worked up has AgentDomain and RegionDomain these can be instanced... but both need "SI" or Service Interfaces basically abstracting U G A I M into classes for re-use and standardizing the protocol chatter On Sat, 2009-07-18 at 11:57 +0100, Alexey Melnikov wrote: > Hi Dave, > > Dave CROCKER wrote: > > > Also: A topic that's been discussed frequently is the difference > > between having a client able to access multiple servers, versus having > > independent servers directly interact. From the draft charter, I > > cannot tell which of these will be covered or how. > > I think this is an important question. There are 3 groups of entities > involved in OGP and the charter doesn't make this clear. > > _______________________________________________ > 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 0050CD29852575F7_= Content-Type: text/html; charset="US-ASCII"
If you look at:
http://www.ietf.org/id/draft-levine-ogp-layering-00.txt

It begins to address this at the requirements and design pattern level. I'd strongly argue, that if its not clear that we want to permit the protocols to work properly in *all* of those deployments patterns, we need to update the charter to make that clear.

My personal perspective is that the OGPX specifications are going to end up defining several hundred "REST" and "RESTish" resources/services, and that grouping and we need to describe how to group and deploy them as deployers see fit. There re some natural clusterings which will be very hard to decouple, but, beyond those, the specifications should strive to give deployers and implementers as much flexibility as possible.

-  David W. Levine
~ Zha Ewry, In Second Life




Kajikawa Jeremy <belxjander@gmail.com>
Sent by: ogpx-bounces@ietf.org

07/18/2009 05:22 AM

To
ogpx@ietf.org
cc
Subject
Re: [ogpx] revised draft charter for OGPX working group





Well a sketch I recently worked up has
 AgentDomain and RegionDomain

these can be instanced...

 but both need "SI" or Service Interfaces
 basically abstracting U G A I M into classes for re-use
 and standardizing the protocol chatter

On Sat, 2009-07-18 at 11:57 +0100, Alexey Melnikov wrote:
> Hi Dave,
>
> Dave CROCKER wrote:
>
> > Also:  A topic that's been discussed frequently is the difference
> > between having a client able to access multiple servers, versus having
> > independent servers directly interact.  From the draft charter, I
> > cannot tell which of these will be covered or how.
>
> I think this is an important question. There are 3 groups of entities
> involved in OGP and the charter doesn't make this clear.
>
> _______________________________________________
> 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 0050CD29852575F7_=-- From meadhbh.siobhan@gmail.com Sat Jul 18 10:10:18 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 865853A696B; Sat, 18 Jul 2009 10:10:18 -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 S1wTfYvAmpPF; Sat, 18 Jul 2009 10:10:17 -0700 (PDT) Received: from mail-yx0-f196.google.com (mail-yx0-f196.google.com [209.85.210.196]) by core3.amsl.com (Postfix) with ESMTP id 42AC03A6965; Sat, 18 Jul 2009 10:10:17 -0700 (PDT) Received: by yxe34 with SMTP id 34so2474192yxe.29 for ; Sat, 18 Jul 2009 10:10:14 -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=lR1uJlVh0MRsvG4xU63LxOzCwrTFv5N7UxUdQeTV/lU=; b=lWXvdvPYCMGoHBMh7pGMsk8/S7xZWYVn3tHI/OucJ1m+SP/tT3O863SaCVrGbo55/V qbHr+h0ZnLtcPlj8+kAYMQ0xcozy6FzHixrtQESsILFFf9KPTHXKlRkchKpKqwXSbrMG UVKP2LnEQ6TOd0e4OOqrpNT5DrlxIuasyppeM= 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=IQYTRxegxTOquo9qHlHNZH53AqVCsgs9saWBzxUMIIspWmAjWRSlOCl8udgZCAPCnG T0OLtGAVPNhF+STTs8lSEirEccNx4THY1ziwW+9U4ECZh2lBY+n8pclh1zTBrVCT0too MYjhs1wLlvxCMSMaTNmroeYN8ORuQqLEp3XbA= MIME-Version: 1.0 Received: by 10.100.12.1 with SMTP id 1mr3382741anl.107.1247937014150; Sat, 18 Jul 2009 10:10:14 -0700 (PDT) In-Reply-To: References: <3a880e2c0907061116r670f8d19t75afd7f4ab733ae1@mail.gmail.com> <4A525917.6090007@dcrocker.net> <4A61AAB3.8050405@isode.com> <1247908974.10607.2.camel@localhost> Date: Sat, 18 Jul 2009 10:10:14 -0700 Message-ID: From: Meadhbh Siobhan To: David W Levine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kajikawa Jeremy , ogpx-bounces@ietf.org, ogpx@ietf.org Subject: Re: [ogpx] revised draft charter for OGPX working group 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, 18 Jul 2009 17:10:18 -0000 @dave crocker . mmm... good feedback, but i think a number of us thought this was such a large design space that it was appropriate to move some details out of the charter and into the "intro and requirements" doc. @kajikawa . right, the role of the agent domain and the region domain are crucial to the protocol. and the LLIDL resource descriptions + documentation of their semantics are supposed to define service interfaces. strictly speaking, we're not developing a software architecture here, but processing expectations _are_ in scope, so understanding what the software looks like would be a "good idea" (tm). @david . right . it CRITICAL that we not create a deployment design space that is so large that we find ourselves working through use cases 10 years from now. the linden deployment pattern is well documented. OpenSIm has a couple deployment patterns: standalone, grid, and probably both with 3rd party cable beach service. we should probably also chat with ryan @ realXtend to see if realXtend and 3di deployment patterns are different from OpenSim. -cheers On Sat, Jul 18, 2009 at 7:42 AM, David W Levine wrote: > > If you look at: > http://www.ietf.org/id/draft-levine-ogp-layering-00.txt > > It begins to address this at the requirements and design pattern level. I= 'd > strongly argue, that if its not clear that we want to permit the protocol= s > to work properly in *all* of those deployments patterns, we need to updat= e > the charter to make that clear. > > My personal perspective is that the OGPX specifications are going to end = up > defining several hundred "REST" and "RESTish" resources/services, and tha= t > grouping and we need to describe how to group and deploy them as deployer= s > see fit. There re some natural clusterings which will be very hard to > decouple, but, beyond those, the specifications should strive to give > deployers and implementers as much flexibility as possible. > > - =A0David W. Levine > ~ Zha Ewry, In Second Life > > > > > Kajikawa Jeremy > Sent by: ogpx-bounces@ietf.org > > 07/18/2009 05:22 AM > > To > ogpx@ietf.org > cc > Subject > Re: [ogpx] revised draft charter for OGPX working group > > > > > Well a sketch I recently worked up has > =A0AgentDomain and RegionDomain > > these can be instanced... > > =A0but both need "SI" or Service Interfaces > =A0basically abstracting U G A I M into classes for re-use > =A0and standardizing the protocol chatter > > On Sat, 2009-07-18 at 11:57 +0100, Alexey Melnikov wrote: >> Hi Dave, >> >> Dave CROCKER wrote: >> >> > Also: =A0A topic that's been discussed frequently is the difference >> > between having a client able to access multiple servers, versus having >> > independent servers directly interact. =A0From the draft charter, I >> > cannot tell which of these will be covered or how. >> >> I think this is an important question. There are 3 groups of entities >> involved in OGP and the charter doesn't make this clear. >> >> _______________________________________________ >> 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 dhc2@dcrocker.net Sat Jul 18 11: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 0902A3A67A3; Sat, 18 Jul 2009 11:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] 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 hUd+QCW1MgdR; Sat, 18 Jul 2009 11:39:40 -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 BAC033A67A1; Sat, 18 Jul 2009 11:39:32 -0700 (PDT) Received: from [192.168.1.104] (ppp-68-120-199-146.dsl.pltn13.pacbell.net [68.120.199.146]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6IIdFAT000369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Jul 2009 11:39:20 -0700 Message-ID: <4A6216CC.5020709@dcrocker.net> Date: Sat, 18 Jul 2009 11:39:08 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Meadhbh Siobhan References: <3a880e2c0907061116r670f8d19t75afd7f4ab733ae1@mail.gmail.com> <4A525917.6090007@dcrocker.net> <4A61AAB3.8050405@isode.com> <1247908974.10607.2.camel@localhost> 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, 18 Jul 2009 11:39:21 -0700 (PDT) Cc: Kajikawa Jeremy , ogpx-bounces@ietf.org, ogpx@ietf.org Subject: Re: [ogpx] revised draft charter for OGPX working group 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: Sat, 18 Jul 2009 18:39:49 -0000 (Apologies for the length of this note. It opened a door, and I've tried to make it as short is practical...) Meadhbh Siobhan wrote: > @dave crocker . mmm... good feedback, but i think a number of us > thought this was such a large design space that it was appropriate to > move some details out of the charter and into the "intro and > requirements" doc. The fact that it touches such large problem, design and solutions spaces is a problem, not a benefit. If the group is to have any focus, it needs to say what it is going to work on, rather specifically. Otherwise it will spend forever trying to decide just that. I believe that, in fact, there is a core of folk, here, who share a specific set of choices. That's what should be documented. And it needs to be documented in a way that those of us outside that core -- and even outside the world of experts in VW, but with protocol design experience -- can understand. A charter says what work is to be done. It needs to have enough detail for that statement to be meaningful to outside readers, so they can tell whether they want to participate, and to give focus to folks working within the group, so that they know not only what the group is trying to do, but what it is NOT trying to do. The "charter and then figure out what we are going to do" approach only works with a topic and participants who have extensive history and focus doing similar work. As soon as the topic is this interesting (ie, complex) and this unfamiliar to open standards space and has this potential diversity of participation, the group usually has difficulty getting adequate agreement. For one thing, there is no charter -- ie, group contract -- for reining in participants who want to push the group into stray areas. By way of being more concrete, here's a version of the charter with some re-working and some comments I've already shared with a few folks privately: ----- My original posting to the ogpx list was because there are some very basic things that I could not discern from the current draft charter. Things that I'd expect from any charter. As a small example, the first paragraph of the charter does not satisfy the requirements of the Working Group Guidlines and Procedures document. Even without that requirement, I see the semantics of the paragraph reducing to: "VW is popular and we should do some standards work on it." That's not my trying to be clever or nasty. I mean that is literally all of the paragraph's semantics. I mean that quite literally: it provides no substantive information to a typical charter reader, in terms of specific problems to be solved, capabilities to be enabled or protocols to be specified. As for the Guidelines requirement(Section 2.2), the essential point is that the first paragraph is circulated independent of the rest of the charter and needs to serve as an abstract, a summary of what the working group is going to accomplish, as a technical effort: "The first paragraph must give a brief summary of the problem area, basis, goal(s) and approach(es) planned for the working group. This paragraph can be used as an overview of the working group's effort." By way of a deeper example of the draft's problems please note that the draft provides no technical explanation for any of the domain that it will be working on. So it uses many terms, such as "virtual worlds" without any technical basis. Let me be clear: As a technical term, I do not know what it means and what it does not mean. Really. But I've got enough technical and standards experience that I should be able to read a charter and tell what is and is not being solved and created, that is, what the concrete value proposition is. But here, I can't. If one already is an expert in the topic, then this stuff is probably clear, although I'll also note that the technical perspectives of long-standing VW workers appears quite divergent, based on the mailing list discussions I've seen. This is what I'd expect for something with a long proprietary history but just entering standardization. If these disparities persist, it is going to be virtually (...) impossible for different views to be understood, nevermind reconciled. When a topic is well-established within the profession, no its nature and technical implications don't need to be explained. But here, yes, we have something that is relatively new and a community that has little or no experience developing standards for it. I believe this is a very basic difference, and one that greatly increases the risk of failure. Over the years, I've come to believe that the technical work of standards is actually the easiest part. Getting everyone on the same page about the problem to be solved and the functionality to be created seems to be the hardest. This requires common perspective and vocabulary. I believe that most working group efforts fail because they do not take care of these basics, along with failing to limit scope sufficiently... BEFORE chartering. While I do realize that a number of the folk participating in this effort have extensive background in this topic and very much ARE on the same page, the question is whether this is to be only a sandbox for them or whether it is to be started and run in a way that encourages participation by others. I hope the latter; it makes the chartering and management side a lot more difficult, but the results a lot more useful, IMO. With respect to explaining terms and concepts, in between a 10-page tutorial and a complete lack of any explanation, there can be summary information and pointers. I give the barest hint of this, below, in a revised the draft. No doubt it's insufficient. A bit -- but only a bit -- more tutorial text and some well-placed citations, would probably be sufficient. Side comment: The charter's repeated use of "application-layer" is something I find distracting, since I do not know what technical import it has, but its use implies substantive import. (By contrast, I don't mind saying "transport" when citing HTTP -- even though HTTP is classed as an apps protocol -- because it properly characterizes the actual role HTTP, or the like, will play for this work.) Equally, is the group: 1. Starting from scratch and creating brand new protocols, 2. Starting with some existing ones but using them only for guidance, 3. Starting with existing ones but making whatever major changes are deemed "useful", or 4. Starting with existing ones and making only "essential" (and minor) changes? Each of these choice has a history of sometimes being appropriate, but they entail wildly different charters and types of work. My guess is that the group's intention is #2 or #3, but I really can't tell from the charter or from the mailing list discussion. Also, to the extent that documents are being used as input, they need to be cited. I see that a number have been released as Internet Drafts that look extremely helpful. They need to be cited, and in terms of the 1-4 list, above. Let me stress that what I am referring to is quite different from trying to get them to agree on resolving differences in solution paradigms. So I'm not suggesting that ogpx should really try to do what mmox couldn't. Rather, the ogpx work should at least be accessible to others. Folks from other VW disciplines and folks from other protocol experience. Based on the current draft charter and the discussion on the list, it isn't. Too much jargon and too little explanation. On the other hand, there were some constructive responses to my query, until you posted a request not to pursue it. In addition, the charter is filled with references that have no obvious technical meaning. As such, the text does not really provide much meaningful guidance about goals and scope, except in the most generic terms. I've attempted to do some re-working of the draft text, at least fixing the first paragraph, but could not get very far with the remainder, because I found so much of the remaining text in need of significant clarification. Here's what I got, along with the questions: {{ Open questions are marked by {{...}} }} Description of Working Group: Virtual Worlds (VWs) and other Massively Multi-Party Online Applications (MMOs) are simulation environments consisting of many objects, object types and virtual actors and users (participants). There are many examples VW and MMO applications, most using proprietary protocols. With their roots in games and social interaction, Virtual Worlds are now being used increasingly in business, education and information exchange. The working group will develop a protocol to enable user clients to access multiple, independently-operated servers. It will also permit servers to share simulation objects and user participant data. For example, a user will be able to have a single, unique presence among independent services. The Open Grid Protocol (OGP) will describe semantics and protocol interaction for the virtual world, independent of transport, though bindings for carrying OGP over HTTP will be defined. {{ one protocol or multiple? the draft charter says "The objective of the OGPX working group is to provide an application-layer wire protocol " and "the Open Grid Protocol suite (OGP), a set of application protocols". Which is it? }} The Open Grid Protocol will define virtual worlds with the following assumptions: * The Virtual World exists independent of the participating clients. {{ what does this mean? }} * Users have a single, unique presence in the virtual world. * The virtual world contains persistent objects. {{ define persistent }} * The virtual world may be partitioned {{ define partitioned }} * Presence, state and simulation occur on authoritative hosts. {{ where else might they occur? what choice is being made here? }} Foundational components of the Open Grid Protocol include the publication of: 1. an abstract dynamic structured data system, suitable for describing the application protocol in a transport-neutral manner, {{ what does dynamic mean, here? what is the alternative? }} 2. clear semantics and mechanisms for carrying OGP messages over message-oriented transports with request/response semantics, {{ UDP is a 'message-oriented' transport, but I suspect that's not what is meant. }} 3. guidelines and mechanisms for host and user authentication and confidentiality, {{ OGPX will define authentication mechanisms? Perhaps is means "Guidines for using existing mutual authentication and confidentiality mechanisms"? }} 4. an application-layer protocol for establishing the user's presence, {{ is 'establishing a presence' different from logging in? if so, how? if not, why not say log in? Given Item #3, I'm guessing this item does NOT mean logging in, since that's the same as authentication, isn't it? Perhaps this item's calling for creating a presence protocol, given that a couple already exist and are used, conflicts with the "use existing" approach of item #3. Why invent a new one? (There might be a good reason to, but it should be justified and maybe debated.) }} 5. an protocol for moving a user's presence from one authoritative host to another, {{ if there are "authoritative" hosts, what other kinds of hosts are there? }} 6. format descriptions for objects and avatars in the virtual world, {{descriptions=specifications? and avatars are not objects? what are they? }} 7. an application-layer protocol for identifying agents, and requesting information about them. {{ is this client/server or server/server? this is a distinct protocol, from any other ogpx work? what does it mean to "identify" agents? }} d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net -- Dave Crocker Brandenburg InternetWorking bbiw.net From meadhbh.siobhan@gmail.com Sat Jul 18 11:53: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 CD22C3A683A; Sat, 18 Jul 2009 11:53: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 n14U4+LPzwzC; Sat, 18 Jul 2009 11:53:34 -0700 (PDT) Received: from mail-yx0-f196.google.com (mail-yx0-f196.google.com [209.85.210.196]) by core3.amsl.com (Postfix) with ESMTP id CB3D03A67A1; Sat, 18 Jul 2009 11:53:33 -0700 (PDT) Received: by yxe34 with SMTP id 34so2520837yxe.29 for ; Sat, 18 Jul 2009 11:51:55 -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=xsbqh8bFlhqQf8NAbBiKfNBNFFiIueB4tadCawHKLnE=; b=OVll8Ts7V3GfA+8IUKNiAKwkfBr8hFNvk7l3QdPm7Ds7kwbMTSmAnjCb1Jd3TV8zlY iNrBjw/rGbYh6OqRRdjdD+kQLQtAdYurrc9x8AEPKG2FuPQKPaVUEXNosr5xWPJ5uC5b L+BTi8R+JMLCL/+B+iP3xtqDtPH0NY8ykaTao= 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=qlbYEl8rRvKNBTxFvjryNAbPK7uf9uqImV50OqoIWxrYbvQe2fFitMnfoXjfA7tPwZ bWQ3ZQ5BCT1FnYdLtbJXFWo4cO5VX4qtcfn13SuJluiI8NVTXB4/LF4VWoXHyAuZhisf DTVvBp345EGG1y/ddNQ66wkqxxteRJRUz4Lzc= MIME-Version: 1.0 Received: by 10.100.12.1 with SMTP id 1mr3505696anl.107.1247943115867; Sat, 18 Jul 2009 11:51:55 -0700 (PDT) In-Reply-To: <4A6216CC.5020709@dcrocker.net> References: <3a880e2c0907061116r670f8d19t75afd7f4ab733ae1@mail.gmail.com> <4A525917.6090007@dcrocker.net> <4A61AAB3.8050405@isode.com> <1247908974.10607.2.camel@localhost> <4A6216CC.5020709@dcrocker.net> Date: Sat, 18 Jul 2009 11:51:55 -0700 Message-ID: From: Meadhbh Siobhan To: dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kajikawa Jeremy , ogpx-bounces@ietf.org, ogpx@ietf.org Subject: Re: [ogpx] revised draft charter for OGPX working group 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, 18 Jul 2009 18:53:36 -0000 again. dave, many of the questions you raise _are_ covered in the intro and requirements doc. On Sat, Jul 18, 2009 at 11:39 AM, Dave CROCKER wrote: > (Apologies for the length of this note. =A0It opened a door, and I've tri= ed to > make it as short is practical...) > > > Meadhbh Siobhan wrote: >> >> @dave crocker . mmm... good feedback, but i think a number of us >> thought this was such a large design space that it was appropriate to >> move some details out of the charter and into the "intro and >> requirements" doc. > > The fact that it touches such large problem, design and solutions spaces = is > a problem, not a benefit. =A0If the group is to have any focus, it needs = to > say what it is going to work on, rather specifically. =A0Otherwise it wil= l > spend forever trying to decide just that. =A0I believe that, in fact, the= re is > a core of folk, here, who share a specific set of choices. =A0That's what > should be documented. And it needs to be documented in a way that those o= f > us outside that core -- and even outside the world of experts in VW, but > with protocol design experience -- can understand. > > A charter says what work is to be done. =A0It needs to have enough detail= for > that statement to be meaningful to outside readers, so they can tell whet= her > they want to participate, and to give focus to folks working within the > group, so that they know not only what the group is trying to do, but wha= t > it is NOT trying to do. > > The "charter and then figure out what we are going to do" approach only > works with a topic and participants who have extensive history and focus > doing similar work. =A0As soon as the topic is this interesting (ie, comp= lex) > and this unfamiliar to open standards space and has this potential divers= ity > of participation, the group usually has difficulty getting adequate > agreement. =A0For one thing, there is no charter -- ie, group contract --= for > reining in participants who want to push the group into stray areas. > > By way of being more concrete, here's a version of the charter with some > re-working and some comments I've already shared with a few folks private= ly: > > > ----- > > > My original posting to the ogpx list was because there are some very basi= c > things that I could not discern from the current draft charter. Things th= at > I'd expect from any charter. =A0As a small example, the first paragraph o= f the > charter does not satisfy the requirements of the Working Group Guidlines = and > Procedures document. =A0Even without that requirement, I see the semantic= s of > the paragraph reducing to: "VW is popular and we should do some standards > work on it." =A0That's not my trying to be clever or nasty. =A0I mean tha= t is > literally all of the paragraph's semantics. =A0I mean that quite literall= y: > =A0it provides no substantive information to a typical charter reader, in > terms of specific problems to be solved, capabilities to be enabled or > protocols to be specified. > > As for the Guidelines requirement(Section 2.2), the essential point is th= at > the first paragraph is circulated independent of the rest of the charter = and > needs to serve as an abstract, a summary of what the working group is goi= ng > to accomplish, as a technical effort: > > =A0 =A0 "The first > =A0 =A0 =A0paragraph must give a brief summary of the problem area, basis= , > =A0 =A0 =A0goal(s) and approach(es) planned for the working group. =A0Thi= s > =A0 =A0 =A0paragraph can be used as an overview of the working group's > =A0 =A0 =A0effort." > > > By way of a deeper example of the draft's problems please note that the > draft provides no technical explanation for any of the domain that it wil= l > be working on. =A0So it uses many terms, such as "virtual worlds" without= any > technical basis. =A0Let me be clear: =A0As a technical term, I do not kno= w what > it means and what it does not mean. =A0Really. =A0But I've got enough tec= hnical > and standards experience that I should be able to read a charter and tell > what is and is not being solved and created, that is, what the concrete > value proposition is. =A0But here, I can't. > > If one already is an expert in the topic, then this stuff is probably cle= ar, > although I'll also note that the technical perspectives of long-standing = VW > workers appears quite divergent, based on the mailing list discussions I'= ve > seen. =A0This is what I'd expect for something with a long proprietary hi= story > but > just entering standardization. =A0If these disparities persist, it is goi= ng to > be > virtually (...) impossible for different views to be understood, nevermin= d > reconciled. > > When a topic is well-established within the profession, no its nature and > technical implications don't need to be explained. =A0But here, yes, we h= ave > something that is relatively new and a community that has little or no > experience developing standards for it. > > I believe this is a very basic difference, and one that greatly increases > the risk of failure. =A0Over the years, I've come to believe that the > technical work of standards is actually the easiest part. =A0Getting ever= yone > on the same page about the problem to be solved and the functionality to = be > created seems to be the hardest. =A0This requires common perspective and > vocabulary. I believe that most working group efforts fail because they d= o > not take care of these basics, along with failing to limit scope > sufficiently... BEFORE chartering. > > While I do realize that a number of the folk participating in this effort > have extensive background in this topic and very much ARE on the same pag= e, > the question is whether this is to be only a sandbox for them or whether = it > is to be started and run in a way that encourages participation by others= . > =A0I hope the latter; it makes the chartering and management side a lot m= ore > difficult, but the results a lot more useful, IMO. > > With respect to explaining terms and concepts, in between a 10-page tutor= ial > and a complete lack of any explanation, there can be summary information = and > pointers. =A0I give the barest hint of this, below, in a revised the draf= t. > =A0No doubt it's insufficient. =A0A bit -- but only a bit -- more tutoria= l text > and some well-placed citations, would probably be sufficient. > > Side comment: =A0The charter's repeated use of "application-layer" is > something I find distracting, since I do not know what technical import i= t > has, but its use implies substantive import. =A0(By contrast, I don't min= d > saying "transport" when citing HTTP -- even though HTTP is classed as an > apps protocol -- because it properly characterizes the actual role HTTP, = or > the like, will play for this work.) > > Equally, is the group: > > =A0 1. Starting from scratch and creating brand new protocols, > > =A0 2. Starting with some existing ones but using them only for guidance, > > =A0 3. Starting with existing ones but making whatever major changes are > deemed "useful", or > > =A0 4. Starting with existing ones and making only "essential" (and minor= ) > changes? > > Each of these choice has a history of sometimes being appropriate, but th= ey > entail wildly different charters and types of work. > > My guess is that the group's intention is #2 or #3, but I really can't te= ll > from the charter or from the mailing list discussion. =A0Also, to the ext= ent > that documents are being used as input, they need to be cited. =A0I see t= hat a > number have been released as Internet Drafts that look extremely helpful. > =A0They need to be cited, and in terms of the 1-4 list, above. > > Let me stress that what I am referring to is quite different from trying = to > get them to agree on resolving differences in solution paradigms. =A0So I= 'm > not suggesting that ogpx should really try to do what mmox couldn't. Rath= er, > the ogpx work should at least be accessible to others. =A0Folks from othe= r VW > disciplines and folks from other protocol experience. =A0Based on the cur= rent > draft charter and the discussion on the list, it isn't. Too much jargon a= nd > too > little explanation. =A0On the other hand, there were some constructive > responses > to my query, until you posted a request not to pursue it. > > In addition, the charter is filled with references that have no obvious > technical meaning. =A0As such, the text does not really provide much > meaningful > guidance about goals and scope, except in the most generic terms. > > I've attempted to do some re-working of the draft text, at least fixing t= he > first paragraph, but could not get very far with the remainder, because I > found > so much of the remaining text in need of significant clarification. > > Here's what I got, along with the questions: > > > =A0 =A0 =A0{{ Open questions are marked by {{...}} }} > > > Description of Working Group: > > =A0 =A0 =A0Virtual Worlds (VWs) and other Massively Multi-Party Online > =A0 =A0 =A0Applications (MMOs) are simulation environments consisting of = many > =A0 =A0 =A0objects, object types and virtual actors and users (participan= ts). > =A0There > =A0 =A0 =A0are many examples VW and MMO applications, most using propriet= ary > =A0 =A0 =A0protocols. With their roots in games and social interaction, V= irtual > =A0 =A0 =A0Worlds are now being used increasingly in business, education = and > =A0 =A0 =A0information exchange. The working group will develop a protoco= l to > enable > =A0 =A0 =A0user clients to access multiple, independently-operated server= s. It > will > =A0 =A0 =A0also permit servers to share simulation objects and user parti= cipant > data. > =A0 =A0 =A0For example, a user =A0will be able to have a single, unique p= resence > among > =A0 =A0 =A0independent services. =A0The Open Grid Protocol (OGP) will des= cribe > =A0 =A0 =A0semantics and protocol =A0interaction for the virtual world, i= ndependent > of > =A0 =A0 =A0transport, though bindings for carrying OGP over HTTP will be = defined. > =A0 =A0 =A0{{ one protocol or multiple? =A0the draft charter says "The ob= jective of > the > =A0 =A0 =A0 =A0 OGPX working group is to provide an application-layer wir= e protocol > " > =A0 =A0 =A0 =A0 and "the Open Grid Protocol suite (OGP), a set of applica= tion > =A0 =A0 =A0 =A0 protocols". =A0Which is it? }} > > =A0 =A0 =A0The Open Grid Protocol will define virtual worlds with the fol= lowing > =A0 =A0 =A0assumptions: > > =A0 =A0 =A0* =A0 =A0 The Virtual World exists independent of the particip= ating > clients. > =A0 =A0 =A0 =A0 =A0 =A0{{ what does this mean? }} > > =A0 =A0 =A0* =A0 =A0 Users have a single, unique presence in the virtual = world. > > =A0 =A0 =A0* =A0 =A0 The virtual world contains persistent objects. > =A0 =A0 =A0 =A0 =A0 =A0{{ define persistent }} > > =A0 =A0 =A0* =A0 =A0 The virtual world may be partitioned > =A0 =A0 =A0 =A0 =A0 =A0{{ define partitioned }} > > =A0 =A0 =A0* =A0 =A0 Presence, state and simulation occur on authoritativ= e hosts. > =A0 =A0 =A0 =A0 =A0 =A0{{ where else might they occur? =A0what choice is = being made here? > }} > > > =A0 =A0 =A0Foundational components of the Open Grid Protocol include the > publication > =A0 =A0 =A0of: > > =A0 =A0 =A01. =A0 =A0an abstract dynamic structured data system, suitable= for > describing > =A0 =A0 =A0 =A0 =A0 =A0the application protocol in a transport-neutral ma= nner, > =A0 =A0 =A0 =A0 =A0 =A0{{ what does dynamic mean, here? =A0what is the al= ternative? }} > > =A0 =A0 =A02. =A0 =A0clear semantics and mechanisms for carrying OGP mess= ages over > =A0 =A0 =A0 =A0 =A0 =A0message-oriented transports with request/response = semantics, > =A0 =A0 =A0 =A0 =A0 =A0{{ UDP is a 'message-oriented' transport, but I su= spect that's > not > =A0 =A0 =A0 =A0 =A0 =A0 =A0 what is meant. }} > > =A0 =A0 =A03. =A0 =A0guidelines and mechanisms for host and user authenti= cation and > =A0 =A0 =A0 =A0 =A0 =A0confidentiality, > =A0 =A0 =A0 =A0 =A0 =A0{{ OGPX will define authentication mechanisms? Per= haps is means > =A0 =A0 =A0 =A0 =A0 =A0 =A0 "Guidines for using existing mutual authentic= ation and > =A0 =A0 =A0 =A0 =A0 =A0 =A0 confidentiality mechanisms"? }} > > =A0 =A0 =A04. =A0 =A0an application-layer protocol for establishing the u= ser's > presence, > =A0 =A0 =A0 =A0 =A0 =A0{{ is 'establishing a presence' different from log= ging in? =A0if > so, > =A0 =A0 =A0 =A0 =A0 =A0 =A0 how? =A0if not, why not say log in? Given Ite= m #3, I'm guessing > =A0 =A0 =A0 =A0 =A0 =A0 =A0 this item does NOT mean logging in, since tha= t's the same as > =A0 =A0 =A0 =A0 =A0 =A0 =A0 authentication, isn't it? =A0Perhaps this ite= m's calling for > =A0 =A0 =A0 =A0 =A0 =A0 =A0 creating a presence protocol, given that a co= uple already > exist > =A0 =A0 =A0 =A0 =A0 =A0 =A0 and are used, conflicts with the "use existin= g" approach of > item > =A0 =A0 =A0 =A0 =A0 =A0 =A0 #3. =A0Why invent a new one? =A0(There might = be a good reason to, > but > =A0 =A0 =A0 =A0 =A0 =A0 =A0 it should be justified and maybe debated.) }} > > =A0 =A0 =A05. =A0 =A0an protocol for moving a user's presence from one au= thoritative > host > =A0 =A0 =A0 =A0 =A0 =A0to another, > =A0 =A0 =A0 =A0 =A0 =A0{{ if there are "authoritative" hosts, what other = kinds of hosts > are > =A0 =A0 =A0 =A0 =A0 =A0 =A0 there? }} > > =A0 =A0 =A06. =A0 =A0format descriptions for objects and avatars in the v= irtual world, > =A0 =A0 =A0 =A0 =A0 =A0{{descriptions=3Dspecifications? =A0and avatars ar= e not objects? > =A0what > =A0 =A0 =A0 =A0 =A0 =A0are they? }} > > =A0 =A0 =A07. =A0 =A0an application-layer protocol for identifying agents= , and > =A0 =A0 =A0 =A0 =A0 =A0requesting information about them. > =A0 =A0 =A0 =A0 =A0 =A0{{ is this client/server or server/server? =A0this= is a distinct > =A0 =A0 =A0 =A0 =A0 =A0 =A0 protocol, from any other ogpx work? =A0what d= oes it mean to > =A0 =A0 =A0 =A0 =A0 =A0 =A0"identify" agents? }} > > > d/ > > -- > > =A0Dave Crocker > =A0Brandenburg InternetWorking > =A0bbiw.net > > > -- > > =A0Dave Crocker > =A0Brandenburg InternetWorking > =A0bbiw.net > From carlo@alinoe.com Sun Jul 19 03:13: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 98AC93A6BD4 for ; Sun, 19 Jul 2009 03:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.83 X-Spam-Level: X-Spam-Status: No, score=-0.83 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, J_CHICKENPOX_46=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 ysxgUtDX6LcL for ; Sun, 19 Jul 2009 03:13:06 -0700 (PDT) Received: from viefep28-int.chello.at (viefep28-int.chello.at [62.179.121.48]) by core3.amsl.com (Postfix) with ESMTP id 13F563A69D8 for ; Sun, 19 Jul 2009 03:13:05 -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 <20090719101225.PEYF14607.viefep17-int.chello.at@edge05.upc.biz>; Sun, 19 Jul 2009 12:12:25 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge05.upc.biz with edge id HmCN1c03G0FlQed05mCPLa; Sun, 19 Jul 2009 12:12:25 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MSTOJ-0004oN-Om; Sun, 19 Jul 2009 12:13:11 +0200 Date: Sun, 19 Jul 2009 12:13:11 +0200 From: Carlo Wood To: Infinity Linden Message-ID: <20090719101311.GA18120@alinoe.com> References: <3a880e2c0906261648k1a14024cudd4cbccb57d8753f@mail.gmail.com> <20090627104731.GB28675@alinoe.com> <20090627110112.GC28675@alinoe.com> <20090627115111.GA30752@alinoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090627115111.GA30752@alinoe.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org Subject: Re: [ogpx] content negotiation for LLSD over HTTP connections 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, 19 Jul 2009 10:13:08 -0000 Ping. On Sat, Jun 27, 2009 at 01:51:11PM +0200, Carlo Wood wrote: > Ok, I made a 'translation' of that IRC page for the purpose of ogpx: > > For documentation purposes there would exist a (central) webpage, > for example http://protocols.ogpx.net, that lists all (accepted) > ogpx server implementations (basically meaning more or less > independent groups working on their own ogpx server versions). > > For example, this page could list the labels: > SecondLife, OpenSim, BlueMoon, which link to websites > controlled by the aforementioned group. Lets call these > "implementation labels" for now. > > Upon connection to a server, the server should send a message > to the client as early as possible (even before authentication, > or order to allow also the authentication method to be altered > in the future) indicating which protocol base it is using. > This would exist of a (list) of triplets exists of a label (string) > a version (integer) and a 'compatibility version' (integer). > > For human readable and documentation reasons, the label should > always start with an "implementation label". It's highly suggested > to just add an integer behind that to complete the label and > make it unique. Lets call these labels "version labels". > For example, the version labels could read "SecondLife23", > "OpenSim1", etc. > > For documentation purposes, each of the aforementioned websites > owned by the different implementer groups should list each of > these version labels with a link to more information about them. > > The version string together with the version defines the (supported) > protocol of the server: every feature, mandatory of optional. > > Neither side has to worry about the mandatory parts, since the > versions will take care of that: a 'compatibility version' is > oldest version that supports all mandatory stuff. > > The client then reacts with the version label and protocol version > it 'requests', as well as all the optional features it wants. > The server confirms which optional features will be used, after > which the protocol is switched to the negotiated protocol. > The client acknowledges this and also switches to the final > protocol. > > As an example, lets assume that one implementation (opensim) > adds a feature that allows clients to better synchronize animations > with sound. They assign the label "anisndsync" to it, which only > really has to be unique within the namespace of OpenSim. > It is made a negotiable feature of 'OpenSim1 version 30'. > > A viewer that has no notion of this feature will logically not > request it, and therefore it will not be used. > > If some grid makes the feature mandatory, the negotation fails > with such a client and the user is told to upgrade to a viewer > that supports 'anisndsync'. I do not consider it very likely > that anyone would make it mandatory however, until -say- 90% > of all viewers already support it, and the 4 year-old viewers > that still don't become really annoying. > > If the client supports it, it will request it (if it's an optional > feature, still) and the server will grant it. Obviously the > server will know about it (it sent 'OpenSim1 30'), or else > the viewer would not have requested it. > > However, then this feauture turns out to not to work - and > the opensim developers decide to remove it again from version > 31. Removing a negotiable feature doesn't break compatiblity, > so there is nothing to indicate to a viewer (that was written > during version 30) that version 31 doesn't support it anymore. > What would happen is this: The server says: Opensim1 31 10. > (where 10 is the compatibility version in this example). > The viewer, only knowing about version 30 and before (that is, > version 10 to 30) doesn't have a clue what changed in > version 31, but it knows that 10 < 30, the version it does > support - and hence it is allowed to react as if the server > is version 30. So, it requests "anisndsync" as before. > This time however, the server doesn't acknowledge it, and > the feature is not used. > > What worried people in the past with this sheme is: > How do the clients keep track of all the features that are > mandatory and/or negotiable for every version? > > Well, this is really very very simple. For each implementated > feature the coder had to sit down and read the documenation. > Along with that documentation come the label and version > number. So, all that is needed is a map from "label + version" > to which *implemented* features are mandatory or negotiable. > The maintenance load of that is neglectable. It will be like > adding two lines of code extra per feature: > > protocol.register("OpenSim1", 30, "anisndsync", &handle_anisndsync); > > and common code that takes care of the whole negotiation > will do the rest. > > Mapping "OpenSim1" to the mandatory and optional features > might involve more code lines, but this code can simply be > copy&pasted from the documentation website of "OpenSim1". > Also this will be something that is easy to maintain (adding > and removing lines per added/delete feature). > > -- > Carlo Wood > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx -- Carlo Wood From morgaine.dinova@googlemail.com Tue Jul 21 01:46: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 99FB23A6A07 for ; Tue, 21 Jul 2009 01:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.246 X-Spam-Level: X-Spam-Status: No, score=-0.246 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_75=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 PBhDX7bUdN91 for ; Tue, 21 Jul 2009 01:46:36 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 32C0C3A6D8D for ; Tue, 21 Jul 2009 01:46:35 -0700 (PDT) Received: by ewy26 with SMTP id 26so2863508ewy.37 for ; Tue, 21 Jul 2009 01:46:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=Z6SxIt+MERX+82cxnCflksCT29aZpGrDqBfSDueO7hM=; b=XIvAliV8SdLtAPnKfDMlHKXjkNq0Zj+tF2BPvKpk59K+XCtOaJ7RQpLdfsothatH0F gzd9X29xXhEsGVpKYDL/znzU9sH9EcSGA18UVz2mEadfTQwdLmjry/2EDttEwrYlxGTY ERCiUmfhLHvyDxrckQNBvxeqVpVakuOs+ezMA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=sWihhhA/L1hq2URWXLKDCsFr5+GgNvv7OZF0YrZDe0ML+CuSZk0+exWk3A482Xnm/Y nOnVmPe5roHJJCr4tXb0jtn/gPt4CRZ/VIInECLRdBszrDmPwINI60k92iXZMg+9Aa2o 4dfG11rqLOEKgvkA29KvCwxungyCgViax+ogg= MIME-Version: 1.0 Received: by 10.210.13.12 with SMTP id 12mr6390976ebm.98.1248165988881; Tue, 21 Jul 2009 01:46:28 -0700 (PDT) Date: Tue, 21 Jul 2009 09:46:28 +0100 Message-ID: From: Morgaine To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=0015174c41d8635558046f334a48 Subject: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds 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, 21 Jul 2009 08:46:38 -0000 --0015174c41d8635558046f334a48 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit A number of weaknesses in the current OGPX charter have been described by others. Here I would like to point out one more. It might be merely the result of inconsistent wording, or it might reflect an important scoping issue for the protocol suite -- it's hard to tell. Either way, the ambiguity should be addressed and removed. The problem arises because of ambiguous use of the terms "Virtual World" and "Virtual Worlds" without explicitly stating whether they are both one and the same or distinct. When we read this loosely with the help of our 2-year prior backround in OGP, the charter seems understandable, but when analysed for independent meaning (as newcomers to the project will need to do) it is more confusing than enlightening in its terminology, as I'll explain. At the heart of the problem is that the key reference document http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 (Open Grid Protocol: Introduction and Requirements) refers to just a single "virtual world", and hence it is out of step with the more common notion that there is a multiplicity of virtual worlds which wish to interoperate. "Virtual world" seems to be conflated with "virtual universe of virtual worlds" or metaverse. To illustrate, http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 refers to a single virtual world as follows (taken from various paragraphs): "This protocol is intended to carry information about the *virtual world*: its shape, its residents and manipulatable objects existing inside the * world*. The objective of the protocol is to define an extensible set of messages for carrying state and state change information between *hosts*participating in the simulation of the *virtual world*." "OGP assumes *hosts* operated by multiple organizations will collaborate to simulate the *virtual world*. It also assumes that services originally defined for other environments (like the world wide web) will enhance the experience of the *virtual world*." "The OGP suite assumes that multiple *hosts* will participate in simulating the *virtual world*." "The *virtual world created by OGP* is intended to be hosted on systems from several different administrative domains." "Initial placement and movement in the *virtual world* is an intricate interaction between *hosts* in the agent domain (which maintain information about the avatar's presence) and *hosts* in the region domain." "If an avatar moves out of the *virtual world region* managed by a particular *simulator* and into a new *simulator*, the client must initiate the transit to the new *simulator*." The above are just a few examples, but there are many others. Tthe document is completely self-consistent in this use of "virtual world" throughout: there is no mention of *interop between virtual worlds* at all, but only between regions of a single virtual world, or worse, between implementation-dependent "simulators". In other words, draft-hamrick-ogp-intro-00 describes the *one-world paradigm of Second Life*, and not the interop between SL and an Opensim-based grid, nor interop between Opensim-based grids, nor interop between single Opensim-based worlds or anything else. That's the background to this. Now let's look at the draft charter. The charter starts off by talking about "Virtual Worlds (VWs)", clearly acknowledging that there are many, and referring to them as "applications". In paragraph 2 it then declares that a goal of OGPX is "to provide an application-layer wire protocol for Virtual Worlds to enable interoperability between applications", and then immediately in the same paragraph jumps into the SL-speak of draft-hamrick-ogp-intro-00: "The Open Grid Protocol (OGP) will describe semantics and protocol interaction for the virtual world". The mixing of "world" and "worlds" continues in paragraph 3, and then the 5 bullet points refer to a single world, but the points are introduced by the sentence "The Open Grid Protocol will define virtual worlds with the following assumptions." Confusion reigns. This might be the result of nothing more than typos and/or inconsistency of wording, rather than any intended one-world agenda. Whichever it is, it's very confusing when one is trying to establish the intended meaning of what is written. For the charter to be useful to the group, its meaning should be plain and the phraseology consistent. First of all, the *intent of OGPX* needs to be clarified. Then the charter needs to be improved to reflect this intent unambiguously. And finally, the various drafts will need revision if they are inconsistent with the amended charter. Morgaine. ============================================================== *Reference*: *OGPX DRAFT CHARTER* (including here as the MIME type on the original file appears to be broken): *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: * Virtual Worlds (VWs) and other Massively Multi-Party Online Applications (MMOs) are of increasing interest to the Internet community. Innumerable examples exist of such applications, most using proprietary protocols. With their roots in games and social interaction, Virtual Worlds are now being used increasingly in business, education and information exchange. With a growing user base, creators of such systems are interested in developing a standard virtual worlds protocol to enable interoperability. The objective of the OGPX working group is to provide an application-layer wire protocol for Virtual Worlds to enable interoperability between applications and provide for access and exchange with other systems on the internet such as web services, e-mail and other information storage systems. The Open Grid Protocol (OGP) will describe semantics and protocol interaction for the virtual world, independent of transport, though bindings for carrying OGP over HTTP will be defined. The core work of the group will be the production of the Open Grid Protocol suite (OGP), a set of application protocols to communicate and interact with the state of Virtual World applications. The Open Grid Protocol will define virtual worlds with the following assumptions: - The Virtual World exists independent of the participating clients. - Users 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 occur on authoritative hosts. Further details regarding the structure of and requirements for virtual worlds described by this group may be found at the document Open Grid Protocol : Introduction and Requirements Foundational components of the Open Grid Protocol include the publication of 1. an abstract dynamic structured data system, suitable for describing the application protocol in a transport-neutral manner, 2. clear semantics and mechanisms for carrying OGP messages over message-oriented transports with request/response semantics, 3. guidelines and mechanisms for host and user authentication and confidentiality, 4. an application-layer protocol for establishing the user's presence, 5. an application-layer protocol for moving a user's presence from one authoritative host to another, 6. format descriptions for objects and avatars in the virtual world, and 7. an application-layer protocol for identifying agents, and requesting information about them. *Goals and Milestones:* - December 2009 "OGP: Requirements and Introduction" to the IESG as an Informational RFC - December 2009 "OGP : Abstract Dynamic Structured Data" to the IESG as Proposed Standard - December 2009 "OGP : Foundational Concepts and Request-Response Transport Bindings" to the IESG as Proposed Standard - April 2010 "OGP : Guidelines for Host Authentication" to the IESG as an Informational RFC - April 2010 "OGP : Service Establishment" to the IESG as Proposed Standard - April 2010 "OGP : Client Application Launch Message" to the IESG as an Informational RFC - April 2010 "OGP : Simulation Presence Establishment" to the IESG as Proposed Standard - August 2010 "OGP : Primitive Object Format" to the IESG as Proposed Standard - August 2010 "OGP : Digital Asset Access" to the IESG as Proposed Standard - December 2010 "OGP : Entity Identifiers" to the IESG as Proposed Standard ============================ END ========================= --0015174c41d8635558046f334a48 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A number of weaknesses in the current OGPX charter have been described by o= thers.=A0 Here I would like to point out one more.=A0 It might be merely th= e result of inconsistent wording, or it might reflect an important scoping = issue for the protocol suite -- it's hard to tell.=A0 Either way, the a= mbiguity should be addressed and removed.

The problem arises because of ambiguous use of the terms "Virtual = World" and "Virtual Worlds" without explicitly stating wheth= er they are both one and the same or distinct.=A0 When we read this loosely= with the help of our 2-year prior backround in OGP, the charter seems unde= rstandable, but when analysed for independent meaning (as newcomers to the = project will need to do) it is more confusing than enlightening in its term= inology, as I'll explain.

At the heart of the problem is that the key reference document http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 (Open Gri= d Protocol: Introduction and Requirements) refers to just a single &= quot;virtual world", and hence it is out of step with the more common = notion that there is a multiplicity of virtual worlds which wish to interop= erate.=A0 "Virtual world" seems to be conflated with "virtua= l universe of virtual worlds" or metaverse.

To illustrate, http://tools.ietf.org/html/draft-hamrick-ogp-in= tro-00 refers to a single virtual world as follows (taken from various = paragraphs):

"This protocol is intended to ca= rry information about the virtual world: its shape, its residents an= d manipulatable objects existing inside the world.=A0 The objective = of the protocol is to define an extensible set of messages for carrying sta= te and state change information between hosts participating in the s= imulation of the virtual world."

"OGP assumes hosts operated by multiple organizations will = collaborate to simulate the virtual world.=A0 It also assumes that s= ervices originally defined for other environments (like the world wide web)= will enhance the experience of the virtual world."

"The OGP suite assumes that multiple hosts will participate= in simulating the virtual world."

"The virtual = world created by OGP is intended to be hosted on systems from several d= ifferent administrative domains."

"Initial placement and movement in the virtual world is an = intricate interaction between hosts in the agent domain (which maint= ain information about the avatar's presence) and hosts in the re= gion domain."

"If an avatar moves out of the virtual world region managed= by a particular simulator and into a new simulator, the clie= nt must initiate the transit to the new simulator."


The above are just a few examples, but there are many others.=A0 = Tthe document is completely self-consistent in this use of "virtual wo= rld" throughout:=A0 there is no mention of interop between virtual = worlds at all, but only between regions of a single virtual world, or w= orse, between implementation-dependent "simulators".

In other words, draft-hamrick-ogp-intro-00 describes the one-worl= d paradigm of Second Life, and not the interop between SL and an Op= ensim-based grid, nor interop between Opensim-based grids, nor interop betw= een single Opensim-based worlds or anything else.

That's the background to this.=A0 Now let's look at the draft c= harter.

The charter starts off by talking about "Virtual Worlds= (VWs)", clearly acknowledging that there are many, and referring to t= hem as "applications".=A0 In paragraph 2 it then declares that a = goal of OGPX is "to provide an application-layer wire protocol for Vir= tual Worlds to enable interoperability between applications", and then= immediately in the same paragraph jumps into the SL-speak of draft-hamrick= -ogp-intro-00:=A0 "The Open Grid Protocol (OGP) will describe semantic= s and protocol interaction for the virtual world".=A0 The mixing of &q= uot;world" and "worlds" continues in paragraph 3, and then t= he 5 bullet points refer to a single world, but the points are introduced b= y the sentence "The Open Grid Protocol will define virtual worlds with= the following assumptions."=A0 Confusion reigns.

This might be the result of nothing more than typos and/or inconsistenc= y of wording, rather than any intended one-world agenda.=A0 Whichever it is= , it's very confusing when one is trying to establish the intended mean= ing of what is written.=A0 For the charter to be useful to the group, its m= eaning should be plain and the phraseology consistent.

First of all, the intent of OGPX needs to be clarified.= =A0 Then the charter needs to be improved to reflect this intent unambiguou= sly.=A0 And finally, the various drafts will need revision if they are inco= nsistent with the amended charter.


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=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
Reference:=A0=A0 OGPX DRAFT CHARTER (including here as= the MIME type on the original file appears to be broken):

Area and Area Directors:

Applications Area


Responsible A= rea Director:

TBD
=A0= =A0=A0
Mailing List:



Description of Working Group:

Virtual Worlds (VWs) and other Massively Multi-Party Online
Appl= ications (MMOs) are of increasing interest to the Internet
community. In= numerable examples exist of such applications, most
using proprietary pr= otocols. With their roots in games and social
interaction, Virtual Worlds are now being used increasingly in
business,= education and information exchange. With a growing user
base, creators = of such systems are interested in developing a
standard virtual worlds p= rotocol to enable interoperability.

The objective of the OGPX working group is to provide an
application= -layer wire protocol for Virtual Worlds to enable
interoperability betwe= en applications and provide for access and
exchange with other systems o= n the internet such as web services,
e-mail and other information storage systems. The Open Grid Protocol
(OG= P) will describe semantics and protocol interaction for the
virtual worl= d, independent of transport, though bindings for
carrying OGP over HTTP = will be defined.

The core work of the group will be the production of the Open
Grid P= rotocol suite (OGP), a set of application protocols to
communicate and i= nteract with the state of Virtual World
applications. The Open Grid Prot= ocol will define virtual worlds with
the following assumptions:

  • The Virtual World exists independ= ent of the participating clients.
  • Users have a single, unique prese= nce in the virtual world.
  • The virtual world contains persistent obj= ects.
  • The virtual world may be partitioned.
  • Presence, state and simul= ation occur on authoritative hosts.

Further details regard= ing the structure of and requirements for virtual
worlds described by th= is group may be found at the document Open
Grid Protocol : Introduction and Requirements

Foundational component= s of the Open Grid Protocol include the publication of
  1. an abstra= ct dynamic structured data system, suitable for describing the application = protocol in a transport-neutral manner,
  2. clear semantics and mechanisms for carrying OGP messages over message-o= riented transports with request/response semantics,
  3. guidelines and = mechanisms for host and user authentication and confidentiality,
  4. an application-layer protocol for establishing the user's presence,
  5. an application-layer protocol for moving a user's presence from on= e authoritative host to another,
  6. format descriptions for objects an= d avatars in the virtual world, and
  7. an application-layer protocol for identifying agents, and requesting in= formation about them.

Goals and Milestones:
  • December 2009 "OGP: Requir= ements and Introduction" to the IESG as an Informational RFC
  • D= ecember 2009 "OGP : Abstract Dynamic Structured Data" to the IESG= as Proposed Standard =A0=A0=A0
  • December 2009 "OGP : Foundational Concepts and Request-Response Tr= ansport Bindings" to the IESG as Proposed Standard
  • April 2010 = "OGP : Guidelines for Host Authentication" to the IESG as an Info= rmational RFC
  • April 2010 "OGP : Service Establishment" to the IESG as Propo= sed Standard
  • April 2010 "OGP : Client Application Launch Messa= ge" to the IESG as an Informational RFC
  • April 2010 "OGP := Simulation Presence Establishment" to the IESG as Proposed Standard
  • August 2010 "OGP : Primitive Object Format" to the IESG as Pr= oposed Standard
  • August 2010 "OGP : Digital Asset Access" = to the IESG as Proposed Standard
  • December 2010 "OGP : Entity I= dentifiers" to the IESG as Proposed Standard
=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 END =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
--0015174c41d8635558046f334a48-- From meadhbh.siobhan@gmail.com Tue Jul 21 08:34: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 3C87F28C2EF for ; Tue, 21 Jul 2009 08:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[AWL=-0.865, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_75=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 2E1tocMo3JS7 for ; Tue, 21 Jul 2009 08:34:41 -0700 (PDT) Received: from mail-yx0-f196.google.com (mail-yx0-f196.google.com [209.85.210.196]) by core3.amsl.com (Postfix) with ESMTP id AF0C53A684C for ; Tue, 21 Jul 2009 08:34:40 -0700 (PDT) Received: by yxe34 with SMTP id 34so5228098yxe.29 for ; Tue, 21 Jul 2009 08:34: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:cc:content-type :content-transfer-encoding; bh=3lDm6ym5kgkfFMlgdnezWdk4pVSfcjlKmOXshwVY1eE=; b=uhdybe+Rpo7jPU8Ff9HV0Sg352rxj9UGQtFUza7S1uK3ztkihz6SgCYG4EwQoS0yaj +5LjqW18SS4ba9sYJhkkESHTgg4+hxvCiGoxsd8kNDRcN+/Rv87yd/ZwiggYQ5uberDN FEsg0BCDVPOtVUiE8NPcV9bCyeoklxv4xKl5Q= 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=fnulhwlwYZobnwfQv5Nf0dZS0C270jV95QxIMoCXEbS82OOKDIvqgec8becbY0a/PS by9sCw21YKpYqGz6uXU3dEY/4Tkgqroy7AYtelAtqqCjZSdegBtbg2UYU3xphZ4ImDnY WEDIQHoxmfiCf4LevwyMvYZbltC7RgM6cUAdM= MIME-Version: 1.0 Received: by 10.100.231.16 with SMTP id d16mr7973811anh.63.1248190472080; Tue, 21 Jul 2009 08:34:32 -0700 (PDT) In-Reply-To: References: Date: Tue, 21 Jul 2009 08:34:31 -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] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds 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, 21 Jul 2009 15:34:42 -0000 morgaine. thanks for the intro into this subject. OGP defines interoperability between the hosts implementing "a" virtual world. this virtual world may be "the" virtual world if there are none other apropos to the conversation at the time. the intro document uses the term "the" virtual world to emphasize the fact that within an OGP protocol interaction, for the purpose of that interaction the endpoints are concerned with THE SAME virtual world. that is, for the purpose of protocol interactions, both endpoints are assumed to be participating in the simulation of the same virtual world. OGP is not a protocol for providing interoperability between different virtual worlds (such as between a Croquet virtual world and an OpenSIm instance.) it is a protocol that communicates application state transitions about THE SAME virtual world. when the OGP specifications use the term "the virtual world" it is assumed they are talking about THE virtual world under discussion to differentiate it from other virtual worlds that might exist. note that this usage is in keeping with several previous standards efforts. X.500, for instance, describes "the directory" yet it is not assumed that there will be a singleton instance of a directory. this is different from "the web" which in common usage seems to imply a single collection of protocol endpoints (even though we're probably all aware that some clients have access to intranet web sites that clients outside a specific administrative domain do not have access to.) that being said... the authors of the OGP specification believe that OGP is capable of providing an "internet scale" virtual world, so who knows, in a decade we may be talking about "the virtual world" the same way we talk about "the web" today. so... to recap... the objective of the OGPX working group is to focus on the OGP family of protocols. it is not to attempt to bridge all virtual worlds with a common access protocol. this may one day happen, but that work is more appropriate for the MMOX group. the definite article in OGP specifications underscores this focus. protocol endpoints in an OGP protocol transaction are concerning themselves with state transitions or queries in the same virtual world, not distinct virtual worlds. -cheers -meadhbh On Tue, Jul 21, 2009 at 1:46 AM, Morgaine w= rote: > A number of weaknesses in the current OGPX charter have been described by > others.=A0 Here I would like to point out one more.=A0 It might be merely= the > result of inconsistent wording, or it might reflect an important scoping > issue for the protocol suite -- it's hard to tell.=A0 Either way, the > ambiguity should be addressed and removed. > > The problem arises because of ambiguous use of the terms "Virtual World" = and > "Virtual Worlds" without explicitly stating whether they are both one and > the same or distinct.=A0 When we read this loosely with the help of our 2= -year > prior backround in OGP, the charter seems understandable, but when analys= ed > for independent meaning (as newcomers to the project will need to do) it = is > more confusing than enlightening in its terminology, as I'll explain. > > At the heart of the problem is that the key reference document > http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 (Open Grid Protocol= : > Introduction and Requirements) refers to just a single "virtual world", a= nd > hence it is out of step with the more common notion that there is a > multiplicity of virtual worlds which wish to interoperate.=A0 "Virtual wo= rld" > seems to be conflated with "virtual universe of virtual worlds" or > metaverse. > > To illustrate, http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 refe= rs > to a single virtual world as follows (taken from various paragraphs): > > "This protocol is intended to carry information about the virtual world: = its > shape, its residents and manipulatable objects existing inside the world. > The objective of the protocol is to define an extensible set of messages = for > carrying state and state change information between hosts participating i= n > the simulation of the virtual world." > > "OGP assumes hosts operated by multiple organizations will collaborate to > simulate the virtual world.=A0 It also assumes that services originally > defined for other environments (like the world wide web) will enhance the > experience of the virtual world." > > "The OGP suite assumes that multiple hosts will participate in simulating > the virtual world." > > "The virtual world created by OGP is intended to be hosted on systems fro= m > several different administrative domains." > > "Initial placement and movement in the virtual world is an intricate > interaction between hosts in the agent domain (which maintain information > about the avatar's presence) and hosts in the region domain." > > "If an avatar moves out of the virtual world region managed by a particul= ar > simulator and into a new simulator, the client must initiate the transit = to > the new simulator." > > > The above are just a few examples, but there are many others.=A0 Tthe doc= ument > is completely self-consistent in this use of "virtual world" throughout: > there is no mention of interop between virtual worlds at all, but only > between regions of a single virtual world, or worse, between > implementation-dependent "simulators". > > In other words, draft-hamrick-ogp-intro-00 describes the one-world paradi= gm > of Second Life, and not the interop between SL and an Opensim-based grid, > nor interop between Opensim-based grids, nor interop between single > Opensim-based worlds or anything else. > > That's the background to this.=A0 Now let's look at the draft charter. > > The charter starts off by talking about "Virtual Worlds (VWs)", clearly > acknowledging that there are many, and referring to them as "applications= ". > In paragraph 2 it then declares that a goal of OGPX is "to provide an > application-layer wire protocol for Virtual Worlds to enable > interoperability between applications", and then immediately in the same > paragraph jumps into the SL-speak of draft-hamrick-ogp-intro-00:=A0 "The = Open > Grid Protocol (OGP) will describe semantics and protocol interaction for = the > virtual world".=A0 The mixing of "world" and "worlds" continues in paragr= aph > 3, and then the 5 bullet points refer to a single world, but the points a= re > introduced by the sentence "The Open Grid Protocol will define virtual > worlds with the following assumptions."=A0 Confusion reigns. > > This might be the result of nothing more than typos and/or inconsistency = of > wording, rather than any intended one-world agenda.=A0 Whichever it is, i= t's > very confusing when one is trying to establish the intended meaning of wh= at > is written.=A0 For the charter to be useful to the group, its meaning sho= uld > be plain and the phraseology consistent. > > First of all, the intent of OGPX needs to be clarified.=A0 Then the chart= er > needs to be improved to reflect this intent unambiguously.=A0 And finally= , the > various drafts will need revision if they are inconsistent with the amend= ed > charter. > > > 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=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 > Reference:=A0=A0 OGPX DRAFT CHARTER (including here as the MIME type on t= he > original file appears to be broken): > > 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: > > Virtual Worlds (VWs) and other Massively Multi-Party Online > Applications (MMOs) are of increasing interest to the Internet > community. Innumerable examples exist of such applications, most > using proprietary protocols. With their roots in games and social > interaction, Virtual Worlds are now being used increasingly in > business, education and information exchange. With a growing user > base, creators of such systems are interested in developing a > standard virtual worlds protocol to enable interoperability. > > The objective of the OGPX working group is to provide an > application-layer wire protocol for Virtual Worlds to enable > interoperability between applications and provide for access and > exchange with other systems on the internet such as web services, > e-mail and other information storage systems. The Open Grid Protocol > (OGP) will describe semantics and protocol interaction for the > virtual world, independent of transport, though bindings for > carrying OGP over HTTP will be defined. > > The core work of the group will be the production of the Open > Grid Protocol suite (OGP), a set of application protocols to > communicate and interact with the state of Virtual World > applications. The Open Grid Protocol will define virtual worlds with > the following assumptions: > > The Virtual World exists independent of the participating clients. > Users 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 occur on authoritative hosts. > > Further details regarding the structure of and requirements for virtual > worlds described by this group may be found at the document Open > Grid Protocol : Introduction and Requirements > > Foundational components of the Open Grid Protocol include the publication= of > > an abstract dynamic structured data system, suitable for describing the > application protocol in a transport-neutral manner, > clear semantics and mechanisms for carrying OGP messages over > message-oriented transports with request/response semantics, > guidelines and mechanisms for host and user authentication and > confidentiality, > an application-layer protocol for establishing the user's presence, > an application-layer protocol for moving a user's presence from one > authoritative host to another, > format descriptions for objects and avatars in the virtual world, and > an application-layer protocol for identifying agents, and requesting > information about them. > > Goals and Milestones: > > December 2009 "OGP: Requirements and Introduction" to the IESG as an > Informational RFC > December 2009 "OGP : Abstract Dynamic Structured Data" to the IESG as > Proposed Standard > December 2009 "OGP : Foundational Concepts and Request-Response Transport > Bindings" to the IESG as Proposed Standard > April 2010 "OGP : Guidelines for Host Authentication" to the IESG as an > Informational RFC > April 2010 "OGP : Service Establishment" to the IESG as Proposed Standard > April 2010 "OGP : Client Application Launch Message" to the IESG as an > Informational RFC > April 2010 "OGP : Simulation Presence Establishment" to the IESG as Propo= sed > Standard > August 2010 "OGP : Primitive Object Format" to the IESG as Proposed Stand= ard > August 2010 "OGP : Digital Asset Access" to the IESG as Proposed Standard > December 2010 "OGP : Entity Identifiers" to the IESG as Proposed Standard > > =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 END =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 > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > From alexey.melnikov@isode.com Tue Jul 21 09:09: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 786DA28C2FA for ; Tue, 21 Jul 2009 09:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 IVOYAkdvIubM for ; Tue, 21 Jul 2009 09:09:26 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 0EFD228C317 for ; Tue, 21 Jul 2009 09:09:26 -0700 (PDT) Received: from [172.16.2.108] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 21 Jul 2009 17:09:15 +0100 Message-ID: <4A65E805.1040507@isode.com> Date: Tue, 21 Jul 2009 17:08:37 +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: Meadhbh Siobhan References: <3a880e2c0907061116r670f8d19t75afd7f4ab733ae1@mail.gmail.com> <4A525917.6090007@dcrocker.net> <4A61AAB3.8050405@isode.com> <1247908974.10607.2.camel@localhost> <4A6216CC.5020709@dcrocker.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: ogpx@ietf.org Subject: Re: [ogpx] revised draft charter for OGPX working group 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, 21 Jul 2009 16:09:27 -0000 Meadhbh Siobhan wrote: >again. dave, many of the questions you raise _are_ covered in the >intro and requirements doc. > > This doesn't matter. The charter should be readable without consulting external documents. From infinity@lindenlab.com Tue Jul 21 11:49: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 17BA828C1FC; Tue, 21 Jul 2009 11:49: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 NHs6t2xO4MGe; Tue, 21 Jul 2009 11:49:52 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by core3.amsl.com (Postfix) with ESMTP id B250A3A6C29; Tue, 21 Jul 2009 11:49:51 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c37so1490496anc.4 for ; Tue, 21 Jul 2009 11:49:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.121.12 with SMTP id t12mr8382926anc.58.1248202182923; Tue, 21 Jul 2009 11:49:42 -0700 (PDT) Date: Tue, 21 Jul 2009 11:49:42 -0700 Message-ID: <3a880e2c0907211149y3905aa46sd0db8828faa8b8b1@mail.gmail.com> From: Infinity Linden To: dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Kajikawa Jeremy , Meadhbh Siobhan , ogpx-bounces@ietf.org, ogpx@ietf.org Subject: [ogpx] proposed scope of OGPX group [was: Re: revised draft charter for OGPX working group] 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, 21 Jul 2009 18:49:53 -0000 hey dave. you've got some really good comments here, but i'm going to split up my responses in an effort to make it easier to carry on different parts of the conversation. i'm going to assume that readers are familiar with the OGP : Intro and Requirements draft ( http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 ), and have at least passing familiarity with previous list conversations. On Sat, Jul 18, 2009 at 11:39 AM, Dave CROCKER wrote: > The fact that it touches such large problem, design and solutions spaces = is > a problem, not a benefit. =A0If the group is to have any focus, it needs = to > say what it is going to work on, rather specifically. =A0Otherwise it wil= l > spend forever trying to decide just that. =A0I believe that, in fact, the= re is > a core of folk, here, who share a specific set of choices. =A0That's what > should be documented. And it needs to be documented in a way that those o= f > us outside that core -- and even outside the world of experts in VW, but > with protocol design experience -- can understand. yes. this was, i believe, the problem with MMOX. we (the OGP implementers) felt that OGP was a fine core for a series of internet standards, but felt it was inappropriate to move forward with such an effort without involvement from users / developers of other protocols. we were hoping that after discussions, we could agree on a set of requirements for a common protocol. instead, what happened was we were unable to even speak the same language, even to the point where there was protracted debate as to what the word "interoperability" meant. that is why, at the end of the MMOX BoF in San Francisco, Lisa asked if there was sufficient interest in forming a group to focus on OGP. i was asked to write a document describing the common assumptions the OGP developers have about the virtual world and it's operating environment. this document became the intro and requirements draft. you can see the core features of the virtual world described in the draft charter reflected in this document. the core points being: * the Virtual World exists independent of the participating clients * users 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 occur on authoritative hosts within the domain of virtual worlds, we believe that this is sufficient to differentiate this effort from other efforts. for example, virtual worlds compliant with the IEEE HLA and DIS specifications make extensive use of co-simulation (where each client application performs virtual world simulation in lock-step with other clients, communicates a digest of the changes it has made to every other client and if other clients provide a different digest, a recovery protocol is entered.) this approach is untenable for an "internet scale" virtual world. > A charter says what work is to be done. =A0It needs to have enough detail= for > that statement to be meaningful to outside readers, so they can tell whet= her > they want to participate, and to give focus to folks working within the > group, so that they know not only what the group is trying to do, but wha= t > it is NOT trying to do. i think the charter is fairly solid in this regard. for instance, we list the following items as being within the scope of the working group: 1. an abstract dynamic structured data system, suitable for describing the application protocol in a transport-neutral manner, 2. clear semantics and mechanisms for carrying OGP messages over message-oriented transports with request/response semantics, 3. guidelines and mechanisms for host and user authentication and confidentiality, 4. an application-layer protocol for establishing the user's presence, 5. an application-layer protocol for moving a user's presence from one authoritative host to another, 6. format descriptions for objects and avatars in the virtual world, and 7. an application-layer protocol for identifying agents, and requesting information about them. and while i agree that a successful working group must know what it shouldn't be working on, there's a problem with enumerating the things a working group isn't. the set of things the proposed working group isn't is untractably large. i understand your concern and you're clearly not saying we have to explicitly mention in the charter that we think "a packet protocol for inter-kitchen-utensil status updates is not within the scope of this working group." (you're not saying that, right?) we are hoping that a "constructive" approach to the working group charter is workable, where we list aspects that are in-scope rather than a "reductive" approach where you assume everything is in scope and explicitly enumerate those which are not. > The "charter and then figure out what we are going to do" approach only > works with a topic and participants who have extensive history and focus > doing similar work. =A0As soon as the topic is this interesting (ie, comp= lex) > and this unfamiliar to open standards space and has this potential divers= ity > of participation, the group usually has difficulty getting adequate > agreement. =A0For one thing, there is no charter -- ie, group contract --= for > reining in participants who want to push the group into stray areas. we are not proposing the "charter and then figure out what we're going to do." that is why we created the requirements and introduction draft and the draft charter and published it on the list: to define those things which we propose to do. > By way of being more concrete, here's a version of the charter with some > re-working and some comments I've already shared with a few folks private= ly: can you please share your version of the charter with the list? i understand that you have made it available privately to some people, but i can't incorporate your changes without knowing what those changes are. From infinity@lindenlab.com Tue Jul 21 16:34: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 132A23A6B90 for ; Tue, 21 Jul 2009 16:34:29 -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 ZZQ0ZkA9VqVb for ; Tue, 21 Jul 2009 16:34:28 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by core3.amsl.com (Postfix) with ESMTP id 347AC28C345 for ; Tue, 21 Jul 2009 16:33:46 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c37so1576604anc.4 for ; Tue, 21 Jul 2009 16:33:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.229.14 with SMTP id b14mr317169anh.187.1248219225567; Tue, 21 Jul 2009 16:33:45 -0700 (PDT) Date: Tue, 21 Jul 2009 16:33:45 -0700 Message-ID: <3a880e2c0907211633p30641775g56cc2ba5e967a9c9@mail.gmail.com> From: Infinity Linden To: ogpx@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [ogpx] charter confusion 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, 21 Jul 2009 23:34:29 -0000 uh oh. just noticed that the trac wiki discussing the BoF ( http://tools.ietf.org/bof ) seems to be pointing to an old version of the draft charter. it's currently pointing to http://www.ietf.org/mail-archive/web/ogpx/current/msg00005.html , which is a bit stale. a more recent version is available at http://www.ietf.org/mail-archive/web/ogpx/current/binYckmHCPRRa.bin . however. for reasons i'm not sure i understand, the mailing list archiving software has munged the mime type for this document. it's contents are valid XHMTL, but my browser tries to intuit content type based on the file extension. cheers meadhbh From alexey.melnikov@isode.com Wed Jul 22 03:56: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 786B53A6ABB for ; Wed, 22 Jul 2009 03:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[AWL=0.608, 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 y8VzfXBeMKyT for ; Wed, 22 Jul 2009 03:56:36 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 664D33A69BD for ; Wed, 22 Jul 2009 03:56:36 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 22 Jul 2009 11:56:13 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4A66F02C.5060105@isode.com> Date: Wed, 22 Jul 2009 11:55:40 +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: <3a880e2c0907211633p30641775g56cc2ba5e967a9c9@mail.gmail.com> In-Reply-To: <3a880e2c0907211633p30641775g56cc2ba5e967a9c9@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: ogpx@ietf.org Subject: Re: [ogpx] charter confusion 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, 22 Jul 2009 10:56:37 -0000 Infinity Linden wrote: >uh oh. just noticed that the trac wiki discussing the BoF ( >http://tools.ietf.org/bof ) seems to be pointing to an old version of >the draft charter. it's currently pointing to >http://www.ietf.org/mail-archive/web/ogpx/current/msg00005.html , >which is a bit stale. a more recent version is available at >http://www.ietf.org/mail-archive/web/ogpx/current/binYckmHCPRRa.bin . > I've updated the BOF page to include the new reference. I've kept the old one, as it is viewable directly from a browser. I can delete it, if you think this would be better. >however. > >for reasons i'm not sure i understand, the mailing list archiving >software has munged the mime type for this document. it's contents are >valid XHMTL, but my browser tries to intuit content type based on the >file extension. > > From dhc2@dcrocker.net Thu Jul 23 06:52: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 00C803A688C for ; Thu, 23 Jul 2009 06:52:25 -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_75=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 SbapRBMpQeHx for ; Thu, 23 Jul 2009 06:52:23 -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 323BD3A683B for ; Thu, 23 Jul 2009 06:52:23 -0700 (PDT) Received: from [127.0.0.1] (adsl-67-127-55-186.dsl.pltn13.pacbell.net [67.127.55.186]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6NDqChJ008603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Jul 2009 06:52:17 -0700 Message-ID: <4A686B0C.9040802@dcrocker.net> Date: Thu, 23 Jul 2009 06:52:12 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Meadhbh Siobhan 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]); Thu, 23 Jul 2009 06:52:18 -0700 (PDT) Cc: ogpx@ietf.org Subject: Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds 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: Thu, 23 Jul 2009 13:52:25 -0000 Meadhbh Siobhan wrote: > morgaine. thanks for the intro into this subject. > > OGP defines interoperability between the hosts implementing "a" > virtual world. this virtual world may be "the" virtual world if there > are none other apropos to the conversation at the time. Can a single host run two instances of OGP, to support two different -- that is, independent -- virtual worlds? Can a single OGP client access two different OGP worlds? That is, VWs that have different names and administration and do not talk to each other? For example, by supporting different domain names an the exchange details of protocol, a single host can run different, independent web or email services.[1] > OGP is not a protocol for providing interoperability between > different virtual worlds (such as between a Croquet virtual world and > an OpenSIm instance.) it is a protocol that communicates application > state transitions about THE SAME virtual world. These two sentences are extremely helpful. For a VW-naive reader like me, they make a basic point clear. In reading the draft charter, I also had wondered about the use of "the" and level of interoperability being sought. The web, email, X.500 and the DNS are examples of having a single integrated service. For email, there is an acknowledgment of other services, by virtue of having "gateways" in the model, but they are entirely secondary to email technical work. The core model is a single integrated service. And that's the usual approach for Internet protocols. But it makes sense that virtual worlds would need to support multiple, INDEPENDENT worlds as discrete instances that do not interoperate. (One could imagine adding some ability to interoperate later, I guess, but I also suspect it would be hugely distracting to make it a goal now.) > when the OGP specifications use the term "the virtual world" it is > assumed they are talking about THE virtual world under discussion to > differentiate it from other virtual worlds that might exist. As minor as it might seem, changing the text to say "a" rather than "the" could also help clarify things, since it moves the entire charter's text over to the perspective that there is more than one and that the work defined by the charter is for a capability that provides a common way to deal with each of multiple instances, albeit separately. > note that this usage is in keeping with several previous standards > efforts. X.500, for instance, describes "the directory" yet it is not > assumed that there will be a singleton instance of a directory. this Actually, that is exactly what it means, as I noted above.[2] Internet protocols usually define a single technical service, but with independent /administration/. Here you are defining multiple services that have a wall between them. Anyhow, this is just the sort of confusion that it helps to have a charter clarify, because it is such a basic point. And your two sentences above (and maybe some very minor wording swapping) clarify things completely, IMO. > the authors of the OGP specification believe that OGP is capable of > providing an "internet scale" virtual world, so who knows, in a decade > we may be talking about "the virtual world" the same way we talk about > "the web" today. That meshes nicely with the approach that has worked well for some other Internet enhancements: rather than requiring everyone to adopt all of a capability from the start, permit incremental adoption, with eventual integration later. > so... to recap... the objective of the OGPX working group is to focus > on the OGP family of protocols. it is not to attempt to bridge all > virtual worlds with a common access protocol. this may one day happen, > but that work is more appropriate for the MMOX group. the definite > article in OGP specifications underscores this focus. protocol > endpoints in an OGP protocol transaction are concerning themselves > with state transitions or queries in the same virtual world, not > distinct virtual worlds. [1] The original Web did not support this, since they didn't include the target domain name in HTTP. Email had this same limitation when first developed. It assumed that the lower-layer transport would do all the work of distinguishing between instances, but that doesn't work. That's why SMTP says explicitly who it is trying to talk to, during session initiation. [2] LDAP was developed as a reaction to adoption problems with X.500. SOme of this was about X.500's complexity, but one of the other problems -- and in some folks' view the much greater one -- was that X.500 put forward a model of complete integration across the Internet. However organization's weren't willing to make their corporate data bases fully integrated with each others'. Worse, there are national laws that constrain this. So, the server-to-server integration that would have created a single, global directory service was dropped. -- Dave Crocker Brandenburg InternetWorking bbiw.net From cfk@pacbell.net Thu Jul 23 07:24: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 18AEB3A67A2 for ; Thu, 23 Jul 2009 07:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_75=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 JoxROdAs9SQT for ; Thu, 23 Jul 2009 07:24:53 -0700 (PDT) Received: from web82608.mail.mud.yahoo.com (web82608.mail.mud.yahoo.com [68.142.201.125]) by core3.amsl.com (Postfix) with SMTP id 4FAA13A6855 for ; Thu, 23 Jul 2009 07:24:53 -0700 (PDT) Received: (qmail 64982 invoked by uid 60001); 23 Jul 2009 14:23:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pacbell.net; s=s1024; t=1248359010; bh=+C74StMppH6IypQruVaPFGZSp69skWX4b87S8i3by6o=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=KxXhKDEZfSGbVVO7jq7tfgC+dUk4FkwQKdslZ2I+nVtz9We0H5/3qEVxaNnfVei6+SiuVLWrr4dPboKDkSfdT85p84eyQgilNaO4ft+pyCX3qExHLWM2i8n4CefDKD2fRz6J3yTkty/4hIXR9dMAzSHCBEhNZljfWVAwLeODn4A= 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=FeMLBoUfyPlTbuhvcaEl2OzYek/LFsXj2qK7rtTzjwY3cgC9/t8WCJNJUaKNAzx9elILlBtq/Llt/7LnPL5rTLx56LtOthtXzHHSQyIzLKDZ07oUa6+8ryly+2Z1sJTJU+Xuv8ZAztuxxzSIcWKE2dsFhRJwP37aKn2KBfbrIk8=; Message-ID: <839559.63575.qm@web82608.mail.mud.yahoo.com> X-YMail-OSG: bDZ96y8VM1nD5L6nzCBr_Ua1.GrBc000KsCiMJUJ0oczpcQVVVXfQoRor4BWZnEe_G5U0QeGHqS2jJe6q5zpmOv_x8_DHrezLwxbePF2BWRlSycbK6cXomIJ2eY3EIQpnGY_QsZDqPo92.xhw676S3RgpFEts8ZVJtMU64crI8v7yjcvgIa7.900iZJzensvWwY6AkV_j1_q6zdSpCvOUUF9crMxItIiTpRKcORL4YxZYgoTJSjqn_XyNcMpCnr6Ec_nA0sqW4dgbLRE5f0YhR7r25hKi75Mwd9q3uQyo6GvMC13GtAKmVyLi6JY6G99nZP6dhLzJDM5crso6B.mNCL6kRfynIDYBFXI Received: from [70.213.130.29] by web82608.mail.mud.yahoo.com via HTTP; Thu, 23 Jul 2009 07:23:30 PDT X-Mailer: YahooMailRC/1357.22 YahooMailWebService/0.7.289.10 References: <4A686B0C.9040802@dcrocker.net> Date: Thu, 23 Jul 2009 07:23:30 -0700 (PDT) From: Charles Krinke To: ogpx@ietf.org In-Reply-To: <4A686B0C.9040802@dcrocker.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-468555922-1248359010=:63575" Subject: Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds 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, 23 Jul 2009 14:24:55 -0000 --0-468555922-1248359010=:63575 Content-Type: text/plain; charset=us-ascii I think we need to view different virtual worlds in the Metaverse in a manner analagous to countries. For instance, OSGrid and SecondLife are independent virtual worlds administered by different groups. The act of moving from one virtual world to another is analagous to traveling from one country to another. There are certain protocols that must be performed at ports between each virtual world. The notion of a 'full handoff' seems appropriate here as this implies a peer relationship between two virtual worlds, and I think that is where the confusion is coming from. As we look forward into the future, we look towards a series of independent virtual worlds, much like countries, as opposed to an overwhelming beauracracy controlled by one virtual world. Charles Krinke ________________________________ From: Dave CROCKER To: Meadhbh Siobhan Cc: ogpx@ietf.org Sent: Thursday, July 23, 2009 6:52:12 AM Subject: Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds Meadhbh Siobhan wrote: > morgaine. thanks for the intro into this subject. > > OGP defines interoperability between the hosts implementing "a" > virtual world. this virtual world may be "the" virtual world if there > are none other apropos to the conversation at the time. Can a single host run two instances of OGP, to support two different -- that is, independent -- virtual worlds? Can a single OGP client access two different OGP worlds? That is, VWs that have different names and administration and do not talk to each other? For example, by supporting different domain names an the exchange details of protocol, a single host can run different, independent web or email services.[1] > OGP is not a protocol for providing interoperability between > different virtual worlds (such as between a Croquet virtual world and > an OpenSIm instance.) it is a protocol that communicates application > state transitions about THE SAME virtual world. These two sentences are extremely helpful. For a VW-naive reader like me, they make a basic point clear. In reading the draft charter, I also had wondered about the use of "the" and level of interoperability being sought. The web, email, X.500 and the DNS are examples of having a single integrated service. For email, there is an acknowledgment of other services, by virtue of having "gateways" in the model, but they are entirely secondary to email technical work. The core model is a single integrated service. And that's the usual approach for Internet protocols. But it makes sense that virtual worlds would need to support multiple, INDEPENDENT worlds as discrete instances that do not interoperate. (One could imagine adding some ability to interoperate later, I guess, but I also suspect it would be hugely distracting to make it a goal now.) > when the OGP specifications use the term "the virtual world" it is > assumed they are talking about THE virtual world under discussion to > differentiate it from other virtual worlds that might exist. As minor as it might seem, changing the text to say "a" rather than "the" could also help clarify things, since it moves the entire charter's text over to the perspective that there is more than one and that the work defined by the charter is for a capability that provides a common way to deal with each of multiple instances, albeit separately. > note that this usage is in keeping with several previous standards > efforts. X.500, for instance, describes "the directory" yet it is not > assumed that there will be a singleton instance of a directory. this Actually, that is exactly what it means, as I noted above.[2] Internet protocols usually define a single technical service, but with independent /administration/. Here you are defining multiple services that have a wall between them. Anyhow, this is just the sort of confusion that it helps to have a charter clarify, because it is such a basic point. And your two sentences above (and maybe some very minor wording swapping) clarify things completely, IMO. > the authors of the OGP specification believe that OGP is capable of > providing an "internet scale" virtual world, so who knows, in a decade > we may be talking about "the virtual world" the same way we talk about > "the web" today. That meshes nicely with the approach that has worked well for some other Internet enhancements: rather than requiring everyone to adopt all of a capability from the start, permit incremental adoption, with eventual integration later. > so... to recap... the objective of the OGPX working group is to focus > on the OGP family of protocols. it is not to attempt to bridge all > virtual worlds with a common access protocol. this may one day happen, > but that work is more appropriate for the MMOX group. the definite > article in OGP specifications underscores this focus. protocol > endpoints in an OGP protocol transaction are concerning themselves > with state transitions or queries in the same virtual world, not > distinct virtual worlds. [1] The original Web did not support this, since they didn't include the target domain name in HTTP. Email had this same limitation when first developed. It assumed that the lower-layer transport would do all the work of distinguishing between instances, but that doesn't work. That's why SMTP says explicitly who it is trying to talk to, during session initiation. [2] LDAP was developed as a reaction to adoption problems with X.500. SOme of this was about X.500's complexity, but one of the other problems -- and in some folks' view the much greater one -- was that X.500 put forward a model of complete integration across the Internet. However organization's weren't willing to make their corporate data bases fully integrated with each others'. Worse, there are national laws that constrain this. So, the server-to-server integration that would have created a single, global directory service was dropped. -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ ogpx mailing list ogpx@ietf.org https://www.ietf.org/mailman/listinfo/ogpx --0-468555922-1248359010=:63575 Content-Type: text/html; charset=us-ascii
I think we need to view different virtual worlds in the Metaverse in a manner analagous to countries. For instance, OSGrid and SecondLife are independent virtual worlds administered by different groups.

The act of moving from one virtual world to another is analagous to traveling from one country to another. There are certain protocols that must be performed at ports between each virtual world.

The notion of a 'full handoff' seems appropriate here as this implies a peer relationship between two virtual worlds, and I think that is where the confusion is coming from. As we look forward into the future, we look towards a series of independent virtual worlds, much like countries, as opposed to an overwhelming beauracracy controlled by one virtual world.

Charles Krinke

From: Dave CROCKER <dhc2@dcrocker.net>
To: Meadhbh Siobhan <meadhbh.siobhan@gmail.com>
Cc: ogpx@ietf.org
Sent: Thursday, July 23, 2009 6:52:12 AM
Subject: Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds



Meadhbh Siobhan wrote:
> morgaine. thanks for the intro into this subject.
>
> OGP defines interoperability between the hosts implementing "a"
> virtual world. this virtual world may be "the" virtual world if there
> are none other apropos to the conversation at the time.

Can a single host run two instances of OGP, to support two different -- that is, independent -- virtual worlds?  Can a single OGP client access two different OGP worlds?  That is, VWs that have different names and administration and do not talk to each other?

For example, by supporting different domain names an the exchange details of protocol, a single host can run different, independent web or email services.[1]


>  OGP is not a protocol for providing interoperability between
> different virtual worlds (such as between a Croquet virtual world and
> an OpenSIm instance.) it is a protocol that communicates application
> state transitions about THE SAME virtual world.

These two sentences are extremely helpful.  For a VW-naive reader like me, they make a basic point clear.

In reading the draft charter, I also had wondered about the use of "the" and level of interoperability being sought.  The web, email, X.500 and the DNS are examples of having a single integrated service. For email, there is an acknowledgment of other services, by virtue of having "gateways" in the model, but they are entirely secondary to email technical work.  The core model is a single integrated service.  And that's the usual approach for Internet protocols.

But it makes sense that virtual worlds would need to support multiple, INDEPENDENT worlds as discrete instances that do not interoperate.  (One could imagine adding some ability to interoperate later, I guess, but I also suspect it would be hugely distracting to make it a goal now.)


> when the OGP specifications use the term "the virtual world" it is
> assumed they are talking about THE virtual world under discussion to
> differentiate it from other virtual worlds that might exist.

As minor as it might seem, changing the text to say "a" rather than "the" could also help clarify things, since it moves the entire charter's text over to the perspective that there is more than one and that the work defined by the charter is for a capability that provides a common way to deal with each of multiple instances, albeit separately.


> note that this usage is in keeping with several previous standards
> efforts. X.500, for instance, describes "the directory" yet it is not
> assumed that there will be a singleton instance of a directory. this

Actually, that is exactly what it means, as I noted above.[2]  Internet protocols usually define a single technical service, but with independent /administration/.  Here you are defining multiple services that have a wall between them.

Anyhow, this is just the sort of confusion that it helps to have a charter clarify, because it is such a basic point.  And your two sentences above (and maybe some very minor wording swapping) clarify things completely, IMO.


> the authors of the OGP specification believe that OGP is capable of
> providing an "internet scale" virtual world, so who knows, in a decade
> we may be talking about "the virtual world" the same way we talk about
> "the web" today.

That meshes nicely with the approach that has worked well for some other Internet enhancements:  rather than requiring everyone to adopt all of a capability from the start, permit incremental adoption, with eventual integration later.


> so... to recap... the objective of the OGPX working group is to focus
> on the OGP family of protocols. it is not to attempt to bridge all
> virtual worlds with a common access protocol. this may one day happen,
> but that work is more appropriate for the MMOX group. the definite
> article in OGP specifications underscores this focus. protocol
> endpoints in an OGP protocol transaction are concerning themselves
> with state transitions or queries in the same virtual world, not
> distinct virtual worlds.


[1] The original Web did not support this, since they didn't include the target domain name in HTTP. Email had this same limitation when first developed. It assumed that the lower-layer transport would do all the work of distinguishing between instances, but that doesn't work.  That's why SMTP says explicitly who it is trying to talk to, during session initiation.

[2] LDAP was developed as a reaction to adoption problems with X.500.  SOme of this was about X.500's complexity, but one of the other problems -- and in some folks' view the much greater one -- was that X.500 put forward a model of complete integration across the Internet. However organization's weren't willing to make their corporate data bases fully integrated with each others'. Worse, there are national laws that constrain this.  So, the server-to-server integration that would have created a single, global directory service was dropped.

--
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx
--0-468555922-1248359010=:63575-- From dwl@us.ibm.com Thu Jul 23 08:33: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 933BA3A6941; Thu, 23 Jul 2009 08:33:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.998 X-Spam-Level: X-Spam-Status: No, score=-4.998 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_75=0.6, 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 wfrkaaH069aW; Thu, 23 Jul 2009 08:33:01 -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 24F073A6783; Thu, 23 Jul 2009 08:33:01 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n6NFPKum009563; Thu, 23 Jul 2009 11:25:20 -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 v9.2) with ESMTP id n6NFVCQr159122; Thu, 23 Jul 2009 11:31:12 -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 n6NFVBmr027069; Thu, 23 Jul 2009 11:31:12 -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 n6NFVBaD027049; Thu, 23 Jul 2009 11:31:11 -0400 In-Reply-To: <4A686B0C.9040802@dcrocker.net> References: <4A686B0C.9040802@dcrocker.net> To: dcrocker@bbiw.net MIME-Version: 1.0 X-KeepSent: 09C84013:1DB388B7-852575FC:0053B041; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Thu, 23 Jul 2009 11:31:11 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5|December 05, 2008) at 07/23/2009 11:31:11, Serialize complete at 07/23/2009 11:31:11 Content-Type: multipart/alternative; boundary="=_alternative 0055406D852575FC_=" Cc: Meadhbh Siobhan , ogpx@ietf.org, ogpx-bounces@ietf.org Subject: Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds 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, 23 Jul 2009 15:33:03 -0000 This is a multipart message in MIME format. --=_alternative 0055406D852575FC_= Content-Type: text/plain; charset="US-ASCII" ogpx-bounces@ietf.org wrote on 07/23/2009 09:52:12 AM: > Dave CROCKER > Sent by: ogpx-bounces@ietf.org > > 07/23/2009 09:52 AM > > Please respond to > dcrocker@bbiw.net > > To > > Meadhbh Siobhan > > cc > > ogpx@ietf.org > > Subject > > Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds > > > > Meadhbh Siobhan wrote: > > morgaine. thanks for the intro into this subject. > > > > OGP defines interoperability between the hosts implementing "a" > > virtual world. this virtual world may be "the" virtual world if there > > are none other apropos to the conversation at the time. > > Can a single host run two instances of OGP, to support two different > -- that is, > independent -- virtual worlds? Can a single OGP client access two > different OGP > worlds? That is, VWs that have different names and administration and do not > talk to each other? > > For example, by supporting different domain names an the exchange details of > protocol, a single host can run different, independent web or email > services.[1] > Absolutely. There's no internal coupling, so a host offering a service, can either use multiple domain names, or, in fact, multiple ports to host totally separate instances. In general, world isn't the way I would think of it. Think of the specification as defining sets of web accessible services, which can be hosted, on arbitrary sets of hosts (including hosting multiple copies of some services on a single host) > > > OGP is not a protocol for providing interoperability between > > different virtual worlds (such as between a Croquet virtual world and > > an OpenSIm instance.) it is a protocol that communicates application > > state transitions about THE SAME virtual world. > > These two sentences are extremely helpful. For a VW-naive reader > like me, they > make a basic point clear. > > In reading the draft charter, I also had wondered about the use of "the" and > level of interoperability being sought. The web, email, X.500 and > the DNS are > examples of having a single integrated service. For email, there is an > acknowledgment of other services, by virtue of having "gateways" in > the model, > but they are entirely secondary to email technical work. The core model is a > single integrated service. And that's the usual approach for > Internet protocols. > > But it makes sense that virtual worlds would need to support multiple, > INDEPENDENT worlds as discrete instances that do not interoperate. > (One could > imagine adding some ability to interoperate later, I guess, but I > also suspect > it would be hugely distracting to make it a goal now.) > > > > when the OGP specifications use the term "the virtual world" it is > > assumed they are talking about THE virtual world under discussion to > > differentiate it from other virtual worlds that might exist. > > As minor as it might seem, changing the text to say "a" rather than > "the" could > also help clarify things, since it moves the entire charter's text > over to the > perspective that there is more than one and that the work defined by > the charter > is for a capability that provides a common way to deal with each of multiple > instances, albeit separately. > > > > note that this usage is in keeping with several previous standards > > efforts. X.500, for instance, describes "the directory" yet it is not > > assumed that there will be a singleton instance of a directory. this > > Actually, that is exactly what it means, as I noted above.[2] Internet > protocols usually define a single technical service, but with independent > /administration/. Here you are defining multiple services that have a wall > between them. > > Anyhow, this is just the sort of confusion that it helps to have a charter > clarify, because it is such a basic point. And your two sentences above (and > maybe some very minor wording swapping) clarify things completely, IMO. > > > > the authors of the OGP specification believe that OGP is capable of > > providing an "internet scale" virtual world, so who knows, in a decade > > we may be talking about "the virtual world" the same way we talk about > > "the web" today. > > That meshes nicely with the approach that has worked well for some other > Internet enhancements: rather than requiring everyone to adopt all of a > capability from the start, permit incremental adoption, with eventual > integration later. Again, if you think of the OGPX specifications as offering a sheaf of deployable services, deployers can incrementally move onto the specifications one service at a time. > > > > so... to recap... the objective of the OGPX working group is to focus > > on the OGP family of protocols. it is not to attempt to bridge all > > virtual worlds with a common access protocol. this may one day happen, > > but that work is more appropriate for the MMOX group. the definite > > article in OGP specifications underscores this focus. protocol > > endpoints in an OGP protocol transaction are concerning themselves > > with state transitions or queries in the same virtual world, not > > distinct virtual worlds. > > > [1] The original Web did not support this, since they didn't include > the target > domain name in HTTP. Email had this same limitation when first developed. It > assumed that the lower-layer transport would do all the work of > distinguishing > between instances, but that doesn't work. That's why SMTP says > explicitly who > it is trying to talk to, during session initiation. > > [2] LDAP was developed as a reaction to adoption problems with X. > 500. SOme of > this was about X.500's complexity, but one of the other problems -- > and in some > folks' view the much greater one -- was that X.500 put forward a model of > complete integration across the Internet. However organization's > weren't willing > to make their corporate data bases fully integrated with each others'. Worse, > there are national laws that constrain this. So, the server-to-server > integration that would have created a single, global directory > service was dropped. > > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx --=_alternative 0055406D852575FC_= Content-Type: text/html; charset="US-ASCII"

ogpx-bounces@ietf.org wrote on 07/23/2009 09:52:12 AM:

> Dave CROCKER <dhc2@dcrocker.net>
> Sent by: ogpx-bounces@ietf.org
>
> 07/23/2009 09:52 AM
>
> Please respond to
> dcrocker@bbiw.net
>
> To
>
> Meadhbh Siobhan <meadhbh.siobhan@gmail.com>
>
> cc
>
> ogpx@ietf.org
>
> Subject
>
> Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds
>
>
>
> Meadhbh Siobhan wrote:
> > morgaine. thanks for the intro into this subject.
> >
> > OGP defines interoperability between the hosts implementing "a"
> > virtual world. this virtual world may be "the" virtual world if there
> > are none other apropos to the conversation at the time.
>
> Can a single host run two instances of OGP, to support two different
> -- that is,
> independent -- virtual worlds?  Can a single OGP client access two
> different OGP
> worlds?  That is, VWs that have different names and administration and do not
> talk to each other?
>
> For example, by supporting different domain names an the exchange details of
> protocol, a single host can run different, independent web or email
> services.[1]
>
Absolutely. There's no internal coupling, so a host offering a service, can either use multiple domain names, or, in fact, multiple ports
to host totally separate instances. In general, world isn't the way I would think of it. Think of the specification as defining sets of web
accessible services, which can be hosted, on arbitrary sets of hosts (including hosting multiple copies of some services on a single host)


>
> >  OGP is not a protocol for providing interoperability between
> > different virtual worlds (such as between a Croquet virtual world and
> > an OpenSIm instance.) it is a protocol that communicates application
> > state transitions about THE SAME virtual world.
>
> These two sentences are extremely helpful.  For a VW-naive reader
> like me, they
> make a basic point clear.
>
> In reading the draft charter, I also had wondered about the use of "the" and
> level of interoperability being sought.  The web, email, X.500 and
> the DNS are
> examples of having a single integrated service. For email, there is an
> acknowledgment of other services, by virtue of having "gateways" in
> the model,
> but they are entirely secondary to email technical work.  The core model is a
> single integrated service.  And that's the usual approach for
> Internet protocols.
>
> But it makes sense that virtual worlds would need to support multiple,
> INDEPENDENT worlds as discrete instances that do not interoperate.  
> (One could
> imagine adding some ability to interoperate later, I guess, but I
> also suspect
> it would be hugely distracting to make it a goal now.)
>
>
> > when the OGP specifications use the term "the virtual world" it is
> > assumed they are talking about THE virtual world under discussion to
> > differentiate it from other virtual worlds that might exist.
>
> As minor as it might seem, changing the text to say "a" rather than
> "the" could
> also help clarify things, since it moves the entire charter's text
> over to the
> perspective that there is more than one and that the work defined by
> the charter
> is for a capability that provides a common way to deal with each of multiple
> instances, albeit separately.
>
>
> > note that this usage is in keeping with several previous standards
> > efforts. X.500, for instance, describes "the directory" yet it is not
> > assumed that there will be a singleton instance of a directory. this
>
> Actually, that is exactly what it means, as I noted above.[2]  Internet
> protocols usually define a single technical service, but with independent
> /administration/.  Here you are defining multiple services that have a wall
> between them.
>
> Anyhow, this is just the sort of confusion that it helps to have a charter
> clarify, because it is such a basic point.  And your two sentences above (and
> maybe some very minor wording swapping) clarify things completely, IMO.
>
>
> > the authors of the OGP specification believe that OGP is capable of
> > providing an "internet scale" virtual world, so who knows, in a decade
> > we may be talking about "the virtual world" the same way we talk about
> > "the web" today.
>
> That meshes nicely with the approach that has worked well for some other
> Internet enhancements:  rather than requiring everyone to adopt all of a
> capability from the start, permit incremental adoption, with eventual
> integration later.
Again, if you think of the OGPX specifications as offering a sheaf of deployable services,
deployers can incrementally move onto the specifications one service at a time.


>
>
> > so... to recap... the objective of the OGPX working group is to focus
> > on the OGP family of protocols. it is not to attempt to bridge all
> > virtual worlds with a common access protocol. this may one day happen,
> > but that work is more appropriate for the MMOX group. the definite
> > article in OGP specifications underscores this focus. protocol
> > endpoints in an OGP protocol transaction are concerning themselves
> > with state transitions or queries in the same virtual world, not
> > distinct virtual worlds.
>
>
> [1] The original Web did not support this, since they didn't include
> the target
> domain name in HTTP. Email had this same limitation when first developed. It
> assumed that the lower-layer transport would do all the work of
> distinguishing
> between instances, but that doesn't work.  That's why SMTP says
> explicitly who
> it is trying to talk to, during session initiation.
>
> [2] LDAP was developed as a reaction to adoption problems with X.
> 500.  SOme of
> this was about X.500's complexity, but one of the other problems --
> and in some
> folks' view the much greater one -- was that X.500 put forward a model of
> complete integration across the Internet. However organization's
> weren't willing
> to make their corporate data bases fully integrated with each others'. Worse,
> there are national laws that constrain this.  So, the server-to-server
> integration that would have created a single, global directory
> service was dropped.
>
> --
>
>    Dave Crocker
>    Brandenburg InternetWorking
>    bbiw.net
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx
 --=_alternative 0055406D852575FC_=-- From lenglish5@cox.net Thu Jul 23 09:52: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 BBA1C3A6844 for ; Thu, 23 Jul 2009 09:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=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 Z4FFBsi0FFaL for ; Thu, 23 Jul 2009 09:52:24 -0700 (PDT) Received: from fed1rmmtao104.cox.net (fed1rmmtao104.cox.net [68.230.241.42]) by core3.amsl.com (Postfix) with ESMTP id D71813A67EF for ; Thu, 23 Jul 2009 09:52:24 -0700 (PDT) Received: from fed1rmimpo03.cox.net ([70.169.32.75]) by fed1rmmtao104.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090723165135.JXWQ17135.fed1rmmtao104.cox.net@fed1rmimpo03.cox.net> for ; Thu, 23 Jul 2009 12:51:35 -0400 Received: from ip72-200-121-127.tc.ph.cox.net ([72.200.121.127]) by fed1rmimpo03.cox.net with bizsmtp id KUra1c0042l1Ksg04UraPm; Thu, 23 Jul 2009 12:51:34 -0400 X-VR-Score: 0.00 X-Authority-Analysis: v=1.0 c=1 a=Wajolswj7cQA:10 a=g0KL02awAAAA:8 a=MBKPDj2DS6sWNYiYZmsA:9 a=r4mbi_wt4w9D_Js88-bospIrY9AA:4 X-CM-Score: 0.00 Message-ID: <4A689516.4060902@cox.net> Date: Thu, 23 Jul 2009 09:51:34 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: ogpx@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [ogpx] possible good refernce for authentication X-BeenThere: ogpx@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Virtual Worlds and the Open Grid Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 16:52:25 -0000 I'm a total newbie at all of this, but I just ran across this website: http://www.authenticationworld.com/Authentication-Federation/ Much good (it seems) information throughout that site. I know what I'm reading for a while... Lawson From dwl@us.ibm.com Thu Jul 23 10:45: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 1F37628C1A0 for ; Thu, 23 Jul 2009 10:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.498 X-Spam-Level: X-Spam-Status: No, score=-5.498 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_75=0.6, 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 B2e2ZxpVmseH for ; Thu, 23 Jul 2009 10:45:45 -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 B2C6728C1AF for ; Thu, 23 Jul 2009 10:43:53 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n6NHIurc002582 for ; Thu, 23 Jul 2009 13:18:56 -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 v9.2) with ESMTP id n6NHQB8d242178 for ; Thu, 23 Jul 2009 13:26:11 -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 n6NHQACJ015143 for ; Thu, 23 Jul 2009 13:26:10 -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 n6NHQA6P015129; Thu, 23 Jul 2009 13:26:10 -0400 In-Reply-To: <4A688A3F.4070300@bbiw.net> References: <4A686B0C.9040802@dcrocker.net> <4A688A3F.4070300@bbiw.net> To: Dave CROCKER MIME-Version: 1.0 X-KeepSent: AAD2FD1B:563587B3-852575FC:005895E4; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Thu, 23 Jul 2009 13:26:10 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5|December 05, 2008) at 07/23/2009 13:26:10, Serialize complete at 07/23/2009 13:26:10 Content-Type: multipart/alternative; boundary="=_alternative 005FC744852575FC_=" Cc: ogpx@ietf.org Subject: Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds 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, 23 Jul 2009 17:45:47 -0000 This is a multipart message in MIME format. --=_alternative 005FC744852575FC_= Content-Type: text/plain; charset="US-ASCII" Dave CROCKER wrote on 07/23/2009 12:05:19 PM: > Dave CROCKER > 07/23/2009 12:05 PM > > To > > David W Levine/Watson/IBM@IBMUS > > cc > > ogpx@ietf.org > > Subject > > Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds > > > > David W Levine wrote: > > > For example, by supporting different domain names an the exchange > > details of > > > protocol, a single host can run different, independent web or email > > > services.[1] > > > > > Absolutely. There's no internal coupling, so a host offering a service, > > can either use multiple domain names, or, in fact, multiple ports > > to host totally separate instances. > > I needed to be clearer: I am not talking about the underlying mechanism that > gets a particular client stream to a particular server instance. > > I am talking about OGP self-identifying which particular instance ofa virtual > world is the target. I think we're getting a confusion here.. because that question sounds slightly ill posed. OGPX aspires to describe internet addressable services. Those services, broadly fall into four buckets. Region services, which describe how to interact with a portion of virtual land. Agent Services which describe how to interact with an agent representing a user, asset and inventory services which focus on storing virtual entities to be used by users and regions, and the services specific to the viewer. (The Linden Lab deployment pattern tends to conflate Agent and inventory/asset services) One assembles a "world" out of some set of the services described in OGPX. Domains also described in the base specs help demarcate trust/admin boundaries. From the perspective of a user, a "world" is a collection of regions which share a map and consistent set of services. (such as Second Life, or the OSGrid or even more precisely, ReactionGrid, or the Rezzable grid.) At the protocol and addressing level, tho, the major addressing construct is URI, mostly mapped onto URLs. If one wants to interact with the OsGrid, for example, one points one's client at OSGrid's Authentication and Login Service, and gives the URI of a region (or says, to the service "Last region I was in" For added fun, one can imagine Regions which are their own little domains, and by default users visiting get agent, asset and inventory services from their home worlds. The underlying mechanism which gets you associated with a region is that you log in an Agent Service, and ask for you avatar to be rezzed in a region. At the protocol level, the region is named as a URI. > > By saying 'port' you are clearly referring to reliance on TCP, or > the like, to > do the differentiation. And indeed, it does help to have the (n-1) layer do > differential delivery. > > But that's not enough. > > Relying solely on the lower layers to do the multiplexing was a > mistake that was > made for email in the 70s and the web in 1989.[1] Each needed to add a > within-protocol construct for identifying sources and sinks > independent of the > lower layer. > > This is an example of an apparently non-intuitive aspect of what it > really means > to be transport independent, which is a stated goal of OGP. > > And as long as we've (or I've) backed into that independence topic, I should > also ask about the reliance on REST. That would seem to make OGP entirely > dependent on the Web, no? > > d/ > REST as a design pattern. And, certainly, in the early going, most deployers are likely to deliver services on http/https endpoints. The specifications explicitly aspire to permit endpoints to be hosted on XMPP, or RTP, or any message oriented transport. Mind you, the basic message oriented HTTP style REST pattern does impose *some* constraints in hosting an endpoint. But, the goal is to keep the resources defined as message sources and sinks, which follow simple RESTish semantics. > [1] Oddly, this surfaced when a network link was set to loop-back and a host > delivered mail to itself, although it was intended for elsewhere... But its > server had no way of knowing that the mail was intended for elsewhere. And > confounding this was that open relaying was acceptable then, so thatthe fact > that the RCPT-TO field had a different domain name didn't help. > > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net --=_alternative 005FC744852575FC_= Content-Type: text/html; charset="US-ASCII"

Dave CROCKER <dcrocker@bbiw.net> wrote on 07/23/2009 12:05:19 PM:

> Dave CROCKER <dcrocker@bbiw.net>
> 07/23/2009 12:05 PM
>
> To
>
> David W Levine/Watson/IBM@IBMUS
>
> cc
>
> ogpx@ietf.org
>
> Subject
>
> Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds
>
>
>
> David W Levine wrote:
> >  > For example, by supporting different domain names an the exchange
> > details of
> >  > protocol, a single host can run different, independent web or email
> >  > services.[1]
> >  >
> > Absolutely. There's no internal coupling, so a host offering a service,
> > can either use multiple domain names, or, in fact, multiple ports
> > to host totally separate instances.
>
> I needed to be clearer:  I am not talking about the underlying mechanism that
> gets a particular client stream to a particular server instance.
>
> I am talking about OGP self-identifying which particular instance ofa virtual
> world is the target.
I think we're getting a confusion here.. because that question sounds slightly ill posed.


OGPX aspires to describe internet addressable services. Those services, broadly fall into
four buckets. Region services, which describe how to interact with a portion of virtual land.
Agent Services which describe how to interact with an agent representing a user, asset and inventory
services which focus on storing virtual entities to be used by users and regions, and the services
specific to the viewer. (The Linden Lab deployment pattern tends to conflate Agent and inventory/asset services)

One assembles a "world" out of some set of the services described in OGPX. Domains also described in the base
specs help demarcate trust/admin boundaries. From the perspective of a user, a "world" is a collection of regions
which share a map and consistent set of services. (such as Second Life, or the OSGrid or even more precisely, ReactionGrid, or
the Rezzable grid.)

At the protocol and addressing level, tho, the major addressing construct is URI, mostly mapped onto URLs. If one wants to
interact with the OsGrid, for example, one points one's client at OSGrid's Authentication and Login Service, and gives the URI of a region (or says, to the service "Last region I was in"

For added fun, one can imagine Regions which are their own little domains, and by default users visiting get agent, asset and inventory services
from their home worlds.

The underlying mechanism which gets you associated with a region is that you log in an Agent Service, and ask for you avatar to be rezzed
in a region. At the protocol level, the region is named as a URI.



>
> By saying 'port' you are clearly referring to reliance on TCP, or
> the like, to
> do the differentiation.  And indeed, it does help to have the (n-1) layer do
> differential delivery.
>
> But that's not enough.
>
> Relying solely on the lower layers to do the multiplexing was a
> mistake that was
> made for email in the 70s and the web in 1989.[1]   Each needed to add a
> within-protocol construct for identifying sources and sinks
> independent of the
> lower layer.
>
> This is an example of an apparently non-intuitive aspect of what it
> really means
> to be transport independent, which is a stated goal of OGP.
>
> And as long as we've (or I've) backed into that independence topic, I should
> also ask about the reliance on REST.  That would seem to make OGP entirely
> dependent on the Web, no?
>
> d/
>
REST as a design pattern. And, certainly, in the early going, most deployers are likely
to deliver services on http/https endpoints. The specifications explicitly aspire to
permit endpoints to be hosted on XMPP, or RTP, or any message oriented transport.

Mind you, the basic message oriented HTTP style REST pattern does impose *some* constraints
in hosting an endpoint. But, the goal is to keep the resources defined as message sources
and sinks, which follow simple RESTish semantics.



> [1] Oddly, this surfaced when a network link was set to loop-back and a host
> delivered mail to itself, although it was intended for elsewhere...  But its
> server had no way of knowing that the mail was intended for elsewhere.  And
> confounding this was that open relaying was acceptable then, so thatthe fact
> that the RCPT-TO field had a different domain name didn't help.
>
> --
>
>    Dave Crocker
>    Brandenburg InternetWorking
>    bbiw.net
 --=_alternative 005FC744852575FC_=-- From cfk@pacbell.net Thu Jul 23 11:26: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 E36DE3A6C6D for ; Thu, 23 Jul 2009 11:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_75=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 EvrjZKgcBC8k for ; Thu, 23 Jul 2009 11:26:10 -0700 (PDT) Received: from web82603.mail.mud.yahoo.com (web82603.mail.mud.yahoo.com [68.142.201.120]) by core3.amsl.com (Postfix) with SMTP id 4C20E3A68A1 for ; Thu, 23 Jul 2009 11:26:09 -0700 (PDT) Received: (qmail 67570 invoked by uid 60001); 23 Jul 2009 18:25:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pacbell.net; s=s1024; t=1248373525; bh=uMaidC9/UoWEiuo7OwbAY/M416jM+GlyYUvss3Y9Xec=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=rVf2LzDG+PGg3y/jWJfMQutdQdBrOUuOYxXGWAP8oYeQphUjAWlHbs2MYpLqpabyfc+fL4fKhUj9tTFjtYFLy9llFNGuETHLeaZW6BPz4qjjpXhMhtBSO1AEb7P6Wo1uYe1wMZZeUJynHvDxf181SvYiv8k/vaG+tmSm4+sxQlc= 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:Cc:In-Reply-To:MIME-Version:Content-Type; b=W2UBy+c3xQ5IlRddrVqhd4xt2iLFVsCOkHHuxrupsrE/9M3B0DoQF2swcLwvahFh26cD8x3tMtkBht5v/BJ55bq1pPzq8Yx9OiQe2Z/tF1Ue2LJPKlLwXtzEoA5Y2iqHVEDkjZlX6jcR3aEoY8ndBRjQvshqwQC+ZdppPh3IaqQ=; Message-ID: <227172.66960.qm@web82603.mail.mud.yahoo.com> X-YMail-OSG: 7iCuG6sVM1lQgdDCOG3FOSuC6y.Yq5eXz9dIZ4Gtd99LnHW10qCkIC0Yxa7WQeHIk3w.IrVtgoJMuQDHiypqWq.vKaX4FTCXNFjzYurzBuL8UFOb8VGIlULWy5BIF5ZIx3a1TnI6LRdbCrdrAXhF4SYh_vJZA98TGIVKwbmNTmxzTo4G4lwOg0X2L4_nBvGo4fPwfknopcJgzJztwtT5iPgvEAdks.fj93GmqgTsl03DBrWDRbuK5ZPoeOIQN19zPl8Wq8rIoSgIDO3SqhrfAFZmGHltSxSf_I0mWYFf6OVDDwwOdfM4CvYk.ZRdQlx1CAyV7.JinDPpnjq69Qt0Ckk- Received: from [70.213.130.29] by web82603.mail.mud.yahoo.com via HTTP; Thu, 23 Jul 2009 11:25:24 PDT X-Mailer: YahooMailRC/1357.22 YahooMailWebService/0.7.289.10 References: <4A686B0C.9040802@dcrocker.net> <4A688A3F.4070300@bbiw.net> Date: Thu, 23 Jul 2009 11:25:24 -0700 (PDT) From: Charles Krinke To: David W Levine , Dave CROCKER In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-563614923-1248373524=:66960" Cc: ogpx@ietf.org Subject: Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds 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, 23 Jul 2009 18:26:21 -0000 --0-563614923-1248373524=:66960 Content-Type: text/plain; charset=us-ascii Dear Zha: That is my understanding also. As we move forward, I can see that the notion of OGP most likely will entail a connection back to the virtual world that one teleported via 'interop' from for certain asset & inventory connections. After all, a user in OSGrid or ReactionGrid will be unknown to SecondLife and the converse is also true. Whether we call these 'grids' or 'virtual worlds' may not matter very much. Personally, I tend to visualize all collections of regions using some sort of common User/Agent/Inventory as a 'grid' rather then a 'virtual world', but that is a small matter of semantics. Charles ________________________________ From: David W Levine To: Dave CROCKER Cc: ogpx@ietf.org Sent: Thursday, July 23, 2009 10:26:10 AM Subject: Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds Dave CROCKER wrote on 07/23/2009 12:05:19 PM: > Dave CROCKER > 07/23/2009 12:05 PM > > To > > David W Levine/Watson/IBM@IBMUS > > cc > > ogpx@ietf.org > > Subject > > Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds > > > > David W Levine wrote: > > > For example, by supporting different domain names an the exchange > > details of > > > protocol, a single host can run different, independent web or email > > > services.[1] > > > > > Absolutely. There's no internal coupling, so a host offering a service, > > can either use multiple domain names, or, in fact, multiple ports > > to host totally separate instances. > > I needed to be clearer: I am not talking about the underlying mechanism that > gets a particular client stream to a particular server instance. > > I am talking about OGP self-identifying which particular instance ofa virtual > world is the target. I think we're getting a confusion here.. because that question sounds slightly ill posed. OGPX aspires to describe internet addressable services. Those services, broadly fall into four buckets. Region services, which describe how to interact with a portion of virtual land. Agent Services which describe how to interact with an agent representing a user, asset and inventory services which focus on storing virtual entities to be used by users and regions, and the services specific to the viewer. (The Linden Lab deployment pattern tends to conflate Agent and inventory/asset services) One assembles a "world" out of some set of the services described in OGPX. Domains also described in the base specs help demarcate trust/admin boundaries. From the perspective of a user, a "world" is a collection of regions which share a map and consistent set of services. (such as Second Life, or the OSGrid or even more precisely, ReactionGrid, or the Rezzable grid.) At the protocol and addressing level, tho, the major addressing construct is URI, mostly mapped onto URLs. If one wants to interact with the OsGrid, for example, one points one's client at OSGrid's Authentication and Login Service, and gives the URI of a region (or says, to the service "Last region I was in" For added fun, one can imagine Regions which are their own little domains, and by default users visiting get agent, asset and inventory services from their home worlds. The underlying mechanism which gets you associated with a region is that you log in an Agent Service, and ask for you avatar to be rezzed in a region. At the protocol level, the region is named as a URI. > > By saying 'port' you are clearly referring to reliance on TCP, or > the like, to > do the differentiation. And indeed, it does help to have the (n-1) layer do > differential delivery. > > But that's not enough. > > Relying solely on the lower layers to do the multiplexing was a > mistake that was > made for email in the 70s and the web in 1989.[1] Each needed to add a > within-protocol construct for identifying sources and sinks > independent of the > lower layer. > > This is an example of an apparently non-intuitive aspect of what it > really means > to be transport independent, which is a stated goal of OGP. > > And as long as we've (or I've) backed into that independence topic, I should > also ask about the reliance on REST. That would seem to make OGP entirely > dependent on the Web, no? > > d/ > REST as a design pattern. And, certainly, in the early going, most deployers are likely to deliver services on http/https endpoints. The specifications explicitly aspire to permit endpoints to be hosted on XMPP, or RTP, or any message oriented transport. Mind you, the basic message oriented HTTP style REST pattern does impose *some* constraints in hosting an endpoint. But, the goal is to keep the resources defined as message sources and sinks, which follow simple RESTish semantics. > [1] Oddly, this surfaced when a network link was set to loop-back and a host > delivered mail to itself, although it was intended for elsewhere... But its > server had no way of knowing that the mail was intended for elsewhere. And > confounding this was that open relaying was acceptable then, so thatthe fact > that the RCPT-TO field had a different domain name didn't help. > > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net --0-563614923-1248373524=:66960 Content-Type: text/html; charset=us-ascii
Dear Zha:

That is my understanding also. As we move forward, I can see that the notion of OGP most likely will entail a connection back to the virtual world that one teleported via 'interop' from for certain asset & inventory connections. After all, a user in OSGrid or ReactionGrid will be unknown to SecondLife and the converse is also true.

Whether we call these 'grids' or 'virtual worlds' may not matter very much. Personally, I tend to visualize all collections of regions using some sort of common User/Agent/Inventory as a 'grid' rather then a 'virtual world', but that is a small matter of semantics.

Charles


From: David W Levine <dwl@us.ibm.com>
To: Dave CROCKER <dcrocker@bbiw.net>
Cc: ogpx@ietf.org
Sent: Thursday, July 23, 2009 10:26:10 AM
Subject: Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds



Dave CROCKER <dcrocker@bbiw.net> wrote on 07/23/2009 12:05:19 PM:

> Dave CROCKER <dcrocker@bbiw.net>
> 07/23/2009 12:05 PM
>
> To
>
> David W Levine/Watson/IBM@IBMUS
>
> cc
>
> ogpx@ietf.org
>
> Subject
>
> Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds
>
>
>
> David W Levine wrote:
> >  > For example, by supporting different domain names an the exchange
> > details of
> >  > protocol, a single host can run different, independent web or email
> >  > services.[1]
> >  >
> > Absolutely. There's no internal coupling, so a host offering a service,
> > can either use multiple domain names, or, in fact, multiple ports
> > to host totally separate instances.
>
> I needed to be clearer:  I am not talking about the underlying mechanism that
> gets a particular client stream to a particular server instance.
>
> I am talking about OGP self-identifying which particular instance ofa virtual
> world is the target.
I think we're getting a confusion here.. because that question sounds slightly ill posed.


OGPX aspires to describe internet addressable services. Those services, broadly fall into
four buckets. Region services, which describe how to interact with a portion of virtual land.
Agent Services which describe how to interact with an agent representing a user, asset and inventory
services which focus on storing virtual entities to be used by users and regions, and the services
specific to the viewer. (The Linden Lab deployment pattern tends to conflate Agent and inventory/asset services)

One assembles a "world" out of some set of the services described in OGPX. Domains also described in the base
specs help demarcate trust/admin boundaries. From the perspective of a user, a "world" is a collection of regions
which share a map and consistent set of services. (such as Second Life, or the OSGrid or even more precisely, ReactionGrid, or
the Rezzable grid.)

At the protocol and addressing level, tho, the major addressing construct is URI, mostly mapped onto URLs. If one wants to
interact with the OsGrid, for example, one points one's client at OSGrid's Authentication and Login Service, and gives the URI of a region (or says, to the service "Last region I was in"

For added fun, one can imagine Regions which are their own little domains, and by default users visiting get agent, asset and inventory services
from their home worlds.

The underlying mechanism which gets you associated with a region is that you log in an Agent Service, and ask for you avatar to be rezzed
in a region. At the protocol level, the region is named as a URI.



>
> By saying 'port' you are clearly referring to reliance on TCP, or
> the like, to
> do the differentiation.  And indeed, it does help to have the (n-1) layer do
> differential delivery.
>
> But that's not enough.
>
> Relying solely on the lower layers to do the multiplexing was a
> mistake that was
> made for email in the 70s and the web in 1989.[1]   Each needed to add a
> within-protocol construct for identifying sources and sinks
> independent of the
> lower layer.
>
> This is an example of an apparently non-intuitive aspect of what it
> really means
> to be transport independent, which is a stated goal of OGP.
>
> And as long as we've (or I've) backed into that independence topic, I should
> also ask about the reliance on REST.  That would seem to make OGP entirely
> dependent on the Web, no?
>
> d/
>
REST as a design pattern. And, certainly, in the early going, most deployers are likely
to deliver services on http/https endpoints. The specifications explicitly aspire to
permit endpoints to be hosted on XMPP, or RTP, or any message oriented transport.

Mind you, the basic message oriented HTTP style REST pattern does impose *some* constraints
in hosting an endpoint. But, the goal is to keep the resources defined as message sources
and sinks, which follow simple RESTish semantics.



> [1] Oddly, this surfaced when a network link was set to loop-back and a host
> delivered mail to itself, although it was intended for elsewhere...  But its
> server had no way of knowing that the mail was intended for elsewhere.  And
> confounding this was that open relaying was acceptable then, so thatthe fact
> that the RCPT-TO field had a different domain name didn't help.
>
> --
>
>    Dave Crocker
>    Brandenburg InternetWorking
>    bbiw.net
--0-563614923-1248373524=:66960-- From dhc@dcrocker.net Thu Jul 23 13:24: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 82A3E3A6A22 for ; Thu, 23 Jul 2009 13:24:56 -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_75=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 KabUary6NokT for ; Thu, 23 Jul 2009 13:24:55 -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 57F563A6941 for ; Thu, 23 Jul 2009 13:24:55 -0700 (PDT) Received: from [192.168.1.35] ([65.206.204.186]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6NKOWmD002268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Jul 2009 13:24:41 -0700 Message-ID: <4A68C6F8.1060405@dcrocker.net> Date: Thu, 23 Jul 2009 13:24:24 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: David W Levine References: <4A686B0C.9040802@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]); Thu, 23 Jul 2009 13:24:41 -0700 (PDT) Cc: ogpx@ietf.org Subject: Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds 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: Thu, 23 Jul 2009 20:24:56 -0000 David W Levine wrote: > > For example, by supporting different domain names an the exchange > details of > > protocol, a single host can run different, independent web or email > > services.[1] > > > Absolutely. There's no internal coupling, so a host offering a service, > can either use multiple domain names, or, in fact, multiple ports > to host totally separate instances. I needed to be clearer: I am not talking about the underlying mechanism that gets a particular client stream to a particular server instance. I am talking about OGP self-identifying which particular instance of a virtual world is the target. By saying 'port' you are clearly referring to reliance on TCP, or the like, to do the differentiation. And indeed, it does help to have the (n-1) layer do differential delivery. But that's not enough. Relying solely on the lower layers to do the multiplexing was a mistake that was made for email in the 70s and the web in 1989.[1] Each needed to add a within-protocol construct for identifying sources and sinks independent of the lower layer. This is an example of an apparently non-intuitive aspect of what it really means to be transport independent, which is a stated goal of OGP. And as long as we've (or I've) backed into that independence topic, I should also ask about the reliance on REST. That would seem to make OGP entirely dependent on the Web, no? d/ [1] Oddly, this surfaced when a network link was set to loop-back and a host delivered mail to itself, although it was intended for elsewhere... But its server had no way of knowing that the mail was intended for elsewhere. And confounding this was that open relaying was acceptable then, so that the fact that the RCPT-TO field had a different domain name didn't help. -- Dave Crocker Brandenburg InternetWorking bbiw.net From infinity@lindenlab.com Fri Jul 24 07:15: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 31C9528C1CA for ; Fri, 24 Jul 2009 07:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_75=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 Z21zkGZrUVHX for ; Fri, 24 Jul 2009 07:15:26 -0700 (PDT) Received: from mail-yx0-f203.google.com (mail-yx0-f203.google.com [209.85.210.203]) by core3.amsl.com (Postfix) with ESMTP id 648793A6B49 for ; Fri, 24 Jul 2009 07:15:26 -0700 (PDT) Received: by yxe41 with SMTP id 41so580623yxe.29 for ; Fri, 24 Jul 2009 07:14:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.239.16 with SMTP id m16mr4450699anh.192.1248444525703; Fri, 24 Jul 2009 07:08:45 -0700 (PDT) In-Reply-To: <227172.66960.qm@web82603.mail.mud.yahoo.com> References: <4A686B0C.9040802@dcrocker.net> <4A688A3F.4070300@bbiw.net> <227172.66960.qm@web82603.mail.mud.yahoo.com> Date: Fri, 24 Jul 2009 07:08:45 -0700 Message-ID: <3a880e2c0907240708g7e172455xa3de69e9e6d616a@mail.gmail.com> From: Infinity Linden To: Charles Krinke Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: ogpx@ietf.org, Dave CROCKER Subject: Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds 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, 24 Jul 2009 14:15:27 -0000 On Thu, Jul 23, 2009 at 11:25 AM, Charles Krinke wrote: > Dear Zha: > > That is my understanding also. As we move forward, I can see that the notion > of OGP most likely will entail a connection back to the virtual world that > one teleported via 'interop' from for certain asset & inventory connections. > After all, a user in OSGrid or ReactionGrid will be unknown to SecondLife > and the converse is also true. > > Whether we call these 'grids' or 'virtual worlds' may not matter very much. > Personally, I tend to visualize all collections of regions using some sort > of common User/Agent/Inventory as a 'grid' rather then a 'virtual world', > but that is a small matter of semantics. +1. i like the term "grid" because it's a slightly newer term than "virtual world" and has less baggage. From infinity@lindenlab.com Fri Jul 24 07: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 EB7323A68E8 for ; Fri, 24 Jul 2009 07:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_75=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 g85SFKtHfc9J for ; Fri, 24 Jul 2009 07:23:24 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by core3.amsl.com (Postfix) with ESMTP id CD6583A6CB7 for ; Fri, 24 Jul 2009 07:23:23 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c37so812233anc.4 for ; Fri, 24 Jul 2009 07:22:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.239.16 with SMTP id m16mr4436986anh.192.1248443974616; Fri, 24 Jul 2009 06:59:34 -0700 (PDT) In-Reply-To: <4A686B0C.9040802@dcrocker.net> References: <4A686B0C.9040802@dcrocker.net> Date: Fri, 24 Jul 2009 06:59:34 -0700 Message-ID: <3a880e2c0907240659t57b8ba4ajd0b9078e2a3ee638@mail.gmail.com> From: Infinity Linden To: dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Meadhbh Siobhan , ogpx@ietf.org Subject: Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds 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, 24 Jul 2009 14:23:26 -0000 On Thu, Jul 23, 2009 at 6:52 AM, Dave CROCKER wrote: > > > Meadhbh Siobhan wrote: >> >> morgaine. thanks for the intro into this subject. >> >> OGP defines interoperability between the hosts implementing "a" >> virtual world. this virtual world may be "the" virtual world if there >> are none other apropos to the conversation at the time. > > Can a single host run two instances of OGP, to support two different -- t= hat > is, independent -- virtual worlds? =A0Can a single OGP client access two > different OGP worlds? =A0That is, VWs that have different names and > administration and do not talk to each other? i'm unsure what you mean by "an instance of OGP." I'm assuming you mean "does the protocol assume that a host (identified by fqdn or ip address) run a single revision of the OGP protocol, possibly in a single server process?" the answer to that would be, of course, "no. there would be no such requirement." i would think it would be analogous to the situation with HTTP. it is possible to run HTTP over any port you like, though port 80 is traditional. additionally, it's quite common to serve pages for different fqdn's off the same ip address and port. this is why it's important for browsers to send a 'Host:' header. but i'm unsure why we're talking about this. the purpose of the specification is to define the protocol, not to provide a software architecture or place limits on the deployment of software which implements the virtual world. if we use the term "network host" in an inappropriate way, that implies that a network host MUST deploy software that implements one and only one revision of the OGP protocol, we should address those documents. entering into an open-ended discussion about the nature of protocols and their relationship to network hosts is probably not in anyone's best interest. to summarize my position... there's nothing in 2616 or 2396 that addresses the issue as to whether it is a violation of the protocol to run an HTTP responder off a port other than port 80. what's changed that we now require such verbiage in draft charters? > For example, by supporting different domain names an the exchange details= of > protocol, a single host can run different, independent web or email > services.[1] are you implying that software that implements HTTP and XMPP, each of which use a destination address is somehow incapable of using that address? i'm very, very confused here. the OGP data formats and protocol flows define the contents of messages and a scheme for using HTTP URIs to resolve the network host and port to send messages to. you are intimating that this is not sufficient, but give examples of deprecated revisions of HTTP and SMTP. OGP is not HTTP. nor is OGP SMTP. OGP is not XMPP. if you are deploying software that implements OGP, and that software supports multiple, distinct virtual worlds that do not share information. you should make sure that the protocol endpoints you publish are sufficiently contextualized to be able to distinguish which distinct virtual world the endpoint exposes an interface for. this is a similar situation to HTTP. many hosting companies will deploy different sites on a single IP address, the server software is capable of route incoming messages to different software (or instances of the same software) based on the Host: header and the path portion of the URL. the Apache developers, when writing their software, made sure their software evaluated the Host: header and used it to route requests to different bits of code that implemented different sites. OGP is different from HTTP, however, in that it makes extensive use of capabilities. capabilities are requested through interaction with a single service URL (like the login URL defined in the auth / service initiation draft.) but the concept is similar: the IP address of the message destination by itself is insufficient to route the message to the logical / conceptual entities responsible for processing the message. so, if you are asking "does the protocol allow a network host to simultaneously support multiple revisions of the OGP protocol?" or "does the protocol allow a network host to service two independent virtual worlds?" the answer to both questions is yes, there is nothing in the protocol that requires a network host to logical virtual world mapping. > > >> =A0OGP is not a protocol for providing interoperability between >> different virtual worlds (such as between a Croquet virtual world and >> an OpenSIm instance.) it is a protocol that communicates application >> state transitions about THE SAME virtual world. > > These two sentences are extremely helpful. =A0For a VW-naive reader like = me, > they make a basic point clear. > > In reading the draft charter, I also had wondered about the use of "the" = and > level of interoperability being sought. =A0The web, email, X.500 and the = DNS > are examples of having a single integrated service. For email, there is a= n > acknowledgment of other services, by virtue of having "gateways" in the > model, but they are entirely secondary to email technical work. =A0The co= re > model is a single integrated service. =A0And that's the usual approach fo= r > Internet protocols. hmm.. the revision of the x.500 spec i worked on made it clear that an entities would be explicitly allowed to have private directories and would not be REQUIRED to integrate to the ill founded international DIT. the example i gave about the web was the example that it is possible to have web pages that are served off servers hosted on private / unroutable IP addresses (or whose FQDNs resolve to private IP addresses, or whose FQDNs are resolved by name resolvers who service ONLY private networks.) we still find the use of the definite article for defining protocol acceptable, even though the defined protocol may clearly be used to implement "a" intranet. but it sounds like we're in violent agreement, so i'll not belabor the poin= t. > But it makes sense that virtual worlds would need to support multiple, > INDEPENDENT worlds as discrete instances that do not interoperate. =A0(On= e > could imagine adding some ability to interoperate later, I guess, but I a= lso > suspect it would be hugely distracting to make it a goal now.) mmm.. i would have to argue against that. or at least encourage it's discussion in the MMOX email list. OGPX is intended to be a working group that focuses on protocol for virtual worlds that share a common set of features: centralized simulation instead of co-simulation, avatars being in one place at one time, etc. other protocols (such as Jon Watte's LESS protocol) diverge from this paradigm significantly. we had a meeting last spring in which we tried to discuss the possibility, but found it difficult to find consensus. i would prefer not to repeat that experiment. so.. yes... it's a great idea. yes... it would be distracting at this point. yes... we should not do it. it is sort of the equivalent of getting the NAPLPS, Gopher and HTTP people in the same room and telling them to integrate their protocols. >> when the OGP specifications use the term "the virtual world" it is >> assumed they are talking about THE virtual world under discussion to >> differentiate it from other virtual worlds that might exist. > > As minor as it might seem, changing the text to say "a" rather than "the" > could also help clarify things, since it moves the entire charter's text > over to the perspective that there is more than one and that the work > defined by the charter is for a capability that provides a common way to > deal with each of multiple instances, albeit separately. aha. so change "The objective of the OGPX working group is to provide an application-layer wire protocol for Virtual Worlds to enable interoperability between applications and provide for access and exchange with other systems on the internet such as web services, e-mail and other information storage systems. The Open Grid Protocol (OGP) will describe semantics and protocol interaction for the virtual world, independent of transport, though bindings for carrying OGP over HTTP will be defined." to "The objective of the OGPX working group is to provide an application-layer wire protocol for use by Virtual Worlds to enable interoperability between applications and provide for access and exchange with other systems on the internet such as web services, e-mail and other information storage systems. The Open Grid Protocol (OGP) will describe semantics and protocol interaction for a virtual world, independent of transport, though bindings for carrying OGP over HTTP will be defined." ??? >> note that this usage is in keeping with several previous standards >> efforts. X.500, for instance, describes "the directory" yet it is not >> assumed that there will be a singleton instance of a directory. this > > Actually, that is exactly what it means, as I noted above.[2] =A0Internet > protocols usually define a single technical service, but with independent > /administration/. =A0Here you are defining multiple services that have a = wall > between them. again. as a participant in the X.500 / X.509 / PEM fiasco, and implementer of those specs, it always seemed to me the specs allowed the use of an independent DIT. that being said, if you chose to not configure your software to add some type of differentiator at the top of your tree, you could get very, very confused, very, very easily. i would argue also that even DNS does not REQUIRE that you point to the same roots, it's just that it's CONSIDERABLY less useful if you don't. (in fact, the last rev of bind/named i looked at included the IP addresses of the roots in a hints file.) hmm.. now that people are getting serious about DNSSEC again, it might even be a discussion that's not completely self-indulgent. but that's more of a discussion to have over coffee / alcohol / food. so with respect to virtual worlds, let me say, "point well taken" and run off and modify some draft charter language. > > Anyhow, this is just the sort of confusion that it helps to have a charte= r > clarify, because it is such a basic point. =A0And your two sentences abov= e > (and maybe some very minor wording swapping) clarify things completely, I= MO. cool. i think we have two competing forces at work here. on one side we have the requirement that the draft charter be clear, but on the other is the requirement that it not define the space so well that the current participants are the only ones who can participate. i think i understand what you're getting at now and have no problems with clarifying language. BUT, we've already removed the list of features that differentiate OGP virtual worlds from other virtual worlds from the charter at your request. i am beginning to get VERY worried that we will soon be back at MMOX. OGPX IS NOT MMOX. We started this effort explicitly to carve off a smaller portion of the problem domain. > > >> the authors of the OGP specification believe that OGP is capable of >> providing an "internet scale" virtual world, so who knows, in a decade >> we may be talking about "the virtual world" the same way we talk about >> "the web" today. > > That meshes nicely with the approach that has worked well for some other > Internet enhancements: =A0rather than requiring everyone to adopt all of = a > capability from the start, permit incremental adoption, with eventual > integration later. i think i can speak for John Hurliman and David Lavine when i say, "we are all about incremental enhancement." > > >> so... to recap... the objective of the OGPX working group is to focus >> on the OGP family of protocols. it is not to attempt to bridge all >> virtual worlds with a common access protocol. this may one day happen, >> but that work is more appropriate for the MMOX group. the definite >> article in OGP specifications underscores this focus. protocol >> endpoints in an OGP protocol transaction are concerning themselves >> with state transitions or queries in the same virtual world, not >> distinct virtual worlds. > > > [1] The original Web did not support this, since they didn't include the > target domain name in HTTP. Email had this same limitation when first > developed. It assumed that the lower-layer transport would do all the wor= k > of distinguishing between instances, but that doesn't work. =A0That's why= SMTP > says explicitly who it is trying to talk to, during session initiation. > > [2] LDAP was developed as a reaction to adoption problems with X.500. =A0= SOme > of this was about X.500's complexity, but one of the other problems -- an= d > in some folks' view the much greater one -- was that X.500 put forward a > model of complete integration across the Internet. However organization's > weren't willing to make their corporate data bases fully integrated with > each others'. Worse, there are national laws that constrain this. =A0So, = the > server-to-server integration that would have created a single, global > directory service was dropped. > > -- > > =A0Dave Crocker > =A0Brandenburg InternetWorking > =A0bbiw.net > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From dwl@us.ibm.com Fri Jul 24 20:11: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 858AB3A67C2; Fri, 24 Jul 2009 20:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.045 X-Spam-Level: X-Spam-Status: No, score=-3.045 tagged_above=-999 required=5 tests=[AWL=-2.287, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_75=0.6, SARE_LWSHORTT=1.24] 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 8vkPNy6nKC-G; Fri, 24 Jul 2009 20:11:09 -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 7F81F3A677C; Fri, 24 Jul 2009 20:11:09 -0700 (PDT) Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e9.ny.us.ibm.com (8.14.3/8.13.1) with ESMTP id n6P3B0xl029770; Fri, 24 Jul 2009 23:11:00 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n6P3B3i3215910; Fri, 24 Jul 2009 23:11:03 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n6P3B3ih019839; Fri, 24 Jul 2009 23:11:03 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n6P3B2gH019835; Fri, 24 Jul 2009 23:11:02 -0400 In-Reply-To: <3a880e2c0907240659t57b8ba4ajd0b9078e2a3ee638@mail.gmail.com> References: <4A686B0C.9040802@dcrocker.net> <3a880e2c0907240659t57b8ba4ajd0b9078e2a3ee638@mail.gmail.com> To: Infinity Linden MIME-Version: 1.0 X-KeepSent: 1024F168:DB913787-852575FE:00101ADD; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Fri, 24 Jul 2009 23:11:02 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5|December 05, 2008) at 07/24/2009 23:11:02, Serialize complete at 07/24/2009 23:11:02 Content-Type: multipart/alternative; boundary="=_alternative 00117D68852575FE_=" Cc: Meadhbh Siobhan , ogpx@ietf.org, ogpx-bounces@ietf.org, dcrocker@bbiw.net Subject: Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds 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, 25 Jul 2009 03:11:10 -0000 This is a multipart message in MIME format. --=_alternative 00117D68852575FE_= Content-Type: text/plain; charset="US-ASCII" Infinity mentioned this, and I thought I'd chime in and agree. The OGPX specifications are built to be incremental. All of the coding work I've done using early versions of the specs confirms this. In fact, the biggest challenge probably isn't going to be permitting incremental change and experimentation, but making sure that we put in enough (and not too much) stuff to manage the consequences of the flexibility. In general, the entire flavor of the specifications is "You start here, and you get handed back details about how the services you want to access are deployed. In particular, the capabilities mechanism is very good at permitting a deployment to map its services onto network endpoints as it sees fit. There are a few, necessarily fixed starting points, from which the dance begins, but, the overall pattern is authenticate, ask for services, and get handed short term use capabilities to access those services. Since the protocols and the design don't dictate any requirement that that the capabilities be serviced on the machine where a client made the request, we get a lot of flexibility. That said, we have no desire to re-create a general distributed computing fabric. The bulk of the specifications are about the bits we believe we need to move to support virtual worlds, not the details of moving those bits. There has been a fair bit of real thinking about how the design patterns are laid out so that you *could* deploy the protocol sequences over different messaging layers than the http(s) The number of actual RESTish web service deployments over XMPP, RTP, or other plausible messaging oriented protocols is pretty small. My personal take is that we have covered most of the bases, but that any real world deployment of the OGPX specifications over a protocol such as XMPP would require a specific RFC on the exact adaptation, and I wouldn't be shocked if it tripped over at least one hidden assumption in the current design. We're trying very hard to stay focused on specifying from working code, with an eye to the future, not the other way around. - David W. Levine ~ Zha Ewry (In Second Life) --=_alternative 00117D68852575FE_= Content-Type: text/html; charset="US-ASCII"
Infinity mentioned this, and I thought I'd chime in and agree. The OGPX specifications are built to be incremental. All of the coding work I've done using early versions of the specs confirms this. In fact, the biggest challenge probably isn't going to be permitting incremental change and experimentation, but making sure that we put in enough (and not too much) stuff to manage the consequences of the flexibility.

In general, the entire flavor of the specifications is "You start here, and you get handed back details about how the services you want to access are deployed. In particular, the capabilities mechanism is very good at permitting a deployment to map its services onto network endpoints as it sees fit. There are a few, necessarily fixed starting points, from which the dance begins, but, the overall pattern is authenticate, ask for services, and get handed short term use capabilities to access those services. Since the protocols and the design don't dictate any requirement that that the capabilities be serviced on the machine where a client made the request, we get a lot of flexibility.

That said, we have no desire to re-create a general distributed computing fabric. The bulk of the specifications are about the bits we believe we need to move to support virtual worlds, not the details of moving those bits. There has been a fair bit of real thinking about how the design patterns are laid out so that you *could* deploy the protocol sequences over different messaging layers than the http(s)  The number of actual RESTish web service deployments over XMPP, RTP, or other plausible messaging oriented protocols is pretty small. My personal take is that we have covered most of the bases, but that any real world deployment of the OGPX specifications over  a protocol such as XMPP would require a specific RFC on the exact adaptation, and I wouldn't be shocked if it tripped over at least one hidden assumption in the current design. We're trying very hard to stay focused on specifying from working code, with an eye to the future, not the other way around.

- David W. Levine
~ Zha Ewry (In Second Life)

--=_alternative 00117D68852575FE_=-- From morgaine.dinova@googlemail.com Fri Jul 24 21:38: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 ABF4C3A69A3; Fri, 24 Jul 2009 21:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.109 X-Spam-Level: X-Spam-Status: No, score=0.109 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_75=0.6, SARE_LWSHORTT=1.24] 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 oSY2cQnrV+TF; Fri, 24 Jul 2009 21:38:58 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id CCBD63A6C35; Fri, 24 Jul 2009 21:38:37 -0700 (PDT) Received: by ewy26 with SMTP id 26so2160482ewy.37 for ; Fri, 24 Jul 2009 21:38:36 -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:cc:content-type; bh=nkAdAU3cOhW5DHYL9ijk1/QFDjFIOkXNhTxeWbdXZvA=; b=DBHXXTih6G7qV/Yqr24VgsAlZAP4zUznhBHOgidZHPIgizwbdruWCXpNBNDPiNYUSt aJGOMQLbzE4jbSwsw2zv/RlKBA7QMMLUWggViYV/GxSvAD+jbyFBToF9GI/F6wdmbu05 n8XEKfSKC7fBTOE/DWk9Y74w8J4tSwM/yjOk0= 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 :cc:content-type; b=rePgq+JbhjVLUREbvrHKCm7vDRQGKUE9v9XEzLm85dKRM1nTkow8ghM5Vz6OrUmeT2 +zjM35zgKjioSwczJm73tkEyswPXd/jBlHAWPoIFvz5LWuQ61EKL6OfUIjR7PvcSm5rs qOm78mzKI5J/xLsdmSiFMEaJg0aIEsvPW7tOQ= MIME-Version: 1.0 Received: by 10.211.178.8 with SMTP id f8mr1941267ebp.75.1248496715900; Fri, 24 Jul 2009 21:38:35 -0700 (PDT) In-Reply-To: References: <4A686B0C.9040802@dcrocker.net> <3a880e2c0907240659t57b8ba4ajd0b9078e2a3ee638@mail.gmail.com> Date: Sat, 25 Jul 2009 05:38:34 +0100 Message-ID: From: Morgaine To: David W Levine Content-Type: multipart/alternative; boundary=0015174c3c664154c7046f804bb4 Cc: Infinity Linden , Meadhbh Siobhan , ogpx@ietf.org, ogpx-bounces@ietf.org, dcrocker@bbiw.net Subject: Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds 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, 25 Jul 2009 04:38:59 -0000 --0015174c3c664154c7046f804bb4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sat, Jul 25, 2009 at 4:11 AM, David W Levine wrote: > > In general, the entire flavor of the specifications is "You start here, and > you get handed back details about how the services you want to access are > deployed. In particular, the capabilities mechanism is very good at > permitting a deployment to map its services onto network endpoints as it > sees fit. There are a few, necessarily fixed starting points, from which the > dance begins, but, the overall pattern is authenticate, ask for services, > and get handed short term use capabilities to access those services. Since > the protocols and the design don't dictate any requirement that that the > capabilities be serviced on the machine where a client made the request, we > get a lot of flexibility. That's an excellent approach, and I'd say *mandatory*, given that we don't know what the future holds in this rapidly changing scene and we don't want to paint ourselves into a corner. Flexibility is crucial, and service endpoint mapping (for want of a better term) provides much flexibility. To put a little more meat on the bones, could you please describe how you see this endpoint mapping working in the area of asset and inventory services (A+IS)? A rough sketch to get us started will do, acknowledging that an actual spec does not yet exist for it. Also, could you please mention how A+IS endpoint mapping might provide or aid flexibility in transferred asset data types? This is an area of very rapid change, with new data types being continually suggested and created, and therefore hardwiring of types would almost immediately paint us into a corner of obsolesence. (I believe I know your answer to this one, given the REST approach, but please summarize it again here, since it has not yet been mentioned on this list and we have new membership.) Regards, Morgaine. On Sat, Jul 25, 2009 at 4:11 AM, David W Levine wrote: > > Infinity mentioned this, and I thought I'd chime in and agree. The OGPX > specifications are built to be incremental. All of the coding work I've done > using early versions of the specs confirms this. In fact, the biggest > challenge probably isn't going to be permitting incremental change and > experimentation, but making sure that we put in enough (and not too much) > stuff to manage the consequences of the flexibility. > > In general, the entire flavor of the specifications is "You start here, and > you get handed back details about how the services you want to access are > deployed. In particular, the capabilities mechanism is very good at > permitting a deployment to map its services onto network endpoints as it > sees fit. There are a few, necessarily fixed starting points, from which the > dance begins, but, the overall pattern is authenticate, ask for services, > and get handed short term use capabilities to access those services. Since > the protocols and the design don't dictate any requirement that that the > capabilities be serviced on the machine where a client made the request, we > get a lot of flexibility. > > That said, we have no desire to re-create a general distributed computing > fabric. The bulk of the specifications are about the bits we believe we need > to move to support virtual worlds, not the details of moving those bits. > There has been a fair bit of real thinking about how the design patterns are > laid out so that you *could* deploy the protocol sequences over different > messaging layers than the http(s) The number of actual RESTish web service > deployments over XMPP, RTP, or other plausible messaging oriented protocols > is pretty small. My personal take is that we have covered most of the bases, > but that any real world deployment of the OGPX specifications over a > protocol such as XMPP would require a specific RFC on the exact adaptation, > and I wouldn't be shocked if it tripped over at least one hidden assumption > in the current design. We're trying very hard to stay focused on specifying > from working code, with an eye to the future, not the other way around. > > - David W. Levine > ~ Zha Ewry (In Second Life) > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --0015174c3c664154c7046f804bb4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Jul 25, 2009 at 4:11 AM, David W Levine <dwl@us.ibm.com> wrote:

In general, the entire flavor of t= he specifications is "You start here, and you get handed back details about how the services you want to access are deployed. In particular, the capabilities mechanism is very good at permitting a deployment to map its services onto network endpoints as it sees fit. There are a few, necess= arily fixed starting points, from which the dance begins, but, the overall patter= n is authenticate, ask for services, and get handed short term use capabiliti= es to access those services. Since the protocols and the design don't dict= ate any requirement that that the capabilities be serviced on the machine where a client made the request, we get a lot of flexibility.

That's an excellent approach, and I'd say m= andatory, given that we don't know what the future holds in this ra= pidly changing scene and we don't want to paint ourselves into a corner= .=A0 Flexibility is crucial, and service endpoint mapping (for want of a be= tter term) provides much flexibility.

To put a little more meat on the bones, could you please describe how y= ou see this endpoint mapping working in the area of asset and inventory ser= vices (A+IS)?=A0 A rough sketch to get us started will do, acknowledging th= at an actual spec does not yet exist for it.

Also, could you please mention how A+IS endpoint mapping might provide = or aid flexibility in transferred asset data types?=A0 This is an area of v= ery rapid change, with new data types being continually suggested and creat= ed, and therefore hardwiring of types would almost immediately paint us int= o a corner of obsolesence.=A0 (I believe I know your answer to this one, gi= ven the REST approach, but please summarize it again here, since it has not= yet been mentioned on this list and we have new membership.)

Regards,

Morgaine.








On Sat, Jul 25, 2009 at 4:11 AM, David W Levine <dwl@us.ibm.com> wrote:

Infinity mentioned this, and I tho= ught I'd chime in and agree. The OGPX specifications are built to be increme= ntal. All of the coding work I've done using early versions of the specs conf= irms this. In fact, the biggest challenge probably isn't going to be permitt= ing incremental change and experimentation, but making sure that we put in enough (and not too much) stuff to manage the consequences of the flexibili= ty.

In general, the entire flavor of t= he specifications is "You start here, and you get handed back details about how the services you want to access are deployed. In particular, the capabilities mechanism is very good at permitting a deployment to map its services onto network endpoints as it sees fit. There are a few, necess= arily fixed starting points, from which the dance begins, but, the overall patter= n is authenticate, ask for services, and get handed short term use capabiliti= es to access those services. Since the protocols and the design don't dict= ate any requirement that that the capabilities be serviced on the machine where a client made the request, we get a lot of flexibility.

That said, we have no desire to re= -create a general distributed computing fabric. The bulk of the specifications are about the bits we believe we need to move to support virtual worlds, not the details of moving those bits. There has been a fair bit of real thinking about how the design patterns are laid out so that you *could* deploy the protocol sequences over different messaging layers than the http(s) =A0The number of actual RESTish web service deployments over XMPP, RTP, or other plausible messaging oriented protocols is pretty small. My personal take is that we have covered most of the bases, but that any real world deployment of the OGPX specifications over =A0a protocol such as XMPP would require a specific RFC on the exact adaptation, and I wouldn't be shocked if it tripped over at least one hidden assumption in the current design. We're trying very hard to stay focused on specif= ying from working code, with an eye to the future, not the other way around.

- David W. Levine
~ Zha Ewry (In Second Life)


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


--0015174c3c664154c7046f804bb4-- From dhc2@dcrocker.net Sat Jul 25 00:08: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 74F973A6ABC for ; Sat, 25 Jul 2009 00:08:54 -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_75=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 uyfDT3xcFbl2 for ; Sat, 25 Jul 2009 00:08:53 -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 3DC7B3A6C32 for ; Sat, 25 Jul 2009 00:08:53 -0700 (PDT) Received: from [10.43.1.48] ([77.241.97.116]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6P78gf9024261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Jul 2009 00:08:49 -0700 Message-ID: <4A6AAF61.4050008@dcrocker.net> Date: Sat, 25 Jul 2009 00:08:17 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: David W Levine References: <4A686B0C.9040802@dcrocker.net> <3a880e2c0907240659t57b8ba4ajd0b9078e2a3ee638@mail.gmail.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]); Sat, 25 Jul 2009 00:08:51 -0700 (PDT) Cc: ogpx@ietf.org Subject: Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds 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: Sat, 25 Jul 2009 07:08:54 -0000 David W Levine wrote: > The number > of actual RESTish web service deployments over XMPP, RTP, or other > plausible messaging oriented protocols is pretty small. David, My impression is that while REST was first defined as a generic computer science construct, it's reality applies only to the Web. Your own language, above, encourage this impression. While I can imagine have "web service deployments over XMPP" I am quite sure it's not going to happen. So say "web service deployment" is to invoke a very elaborate set of services. As soon as we talk about operating over xmpp, RTP or some other transport, we are no longer talking about the web. If OGP is a web service, then it is tied to the web and the web uses HTTP for transfer. If OGP is not tied to the web, then any reference to transfer needs to be independent of web terminology and mechanisms. If indeed transport independence is a goal -- and FWIW it's a goal I'm in favor of -- then anything having to do with the web needs to be carefully partitioned, with literally no direct OGP reference to it. The partitioning would provide a distinct OGP-over-the-web encapsulation specification. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Sat Jul 25 00:53: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 499A728C11A for ; Sat, 25 Jul 2009 00:53:22 -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_75=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 VQNgzWiF3W4N for ; Sat, 25 Jul 2009 00:53:20 -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 D423028C0F3 for ; Sat, 25 Jul 2009 00:53:19 -0700 (PDT) Received: from [10.43.1.48] ([77.241.97.116]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6P7qvvV027107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 25 Jul 2009 00:53:04 -0700 Message-ID: <4A6AB9C0.6090109@dcrocker.net> Date: Sat, 25 Jul 2009 00:52:32 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Infinity Linden References: <4A686B0C.9040802@dcrocker.net> <3a880e2c0907240659t57b8ba4ajd0b9078e2a3ee638@mail.gmail.com> In-Reply-To: <3a880e2c0907240659t57b8ba4ajd0b9078e2a3ee638@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]); Sat, 25 Jul 2009 00:53:06 -0700 (PDT) Cc: Meadhbh Siobhan , ogpx@ietf.org, dcrocker@bbiw.net Subject: Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds 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: Sat, 25 Jul 2009 07:53:22 -0000 Infinity Linden wrote: >> Can a single host run two instances of OGP, to support two different -- that >> is, independent -- virtual worlds? Can a single OGP client access two >> different OGP worlds? That is, VWs that have different names and >> administration and do not talk to each other? > > i'm unsure what you mean by "an instance of OGP." I'm assuming you > mean "does the protocol assume that a host (identified by fqdn or ip > address) run a single revision of the OGP protocol, possibly in a > single server process?" I think I mean something different from that. Brandenburg (bbiw.net) and DKIM (dkim.org) are hosted on the same machine. Imagine that each organization wants to run entirely private (independent) VW/grids. I might choose to participate in each, but other than some individual participants that they might happen to have in common, nothing else about them is visibly shared. The question is whether a user who is accessing the hosting machine can adequately indicate which VW they want, without relying on lower-layer information? What is the technical basis the server users for determining that one time my access is to the bbiw.net VW and another time it is to the dkim.org one? Assuming that the server can make the distinction, must it use information from outside of OGP, such as transport-specific information? > i would think it would be analogous to the situation with HTTP. it is > possible to run HTTP over any port you like, though port 80 is > traditional. additionally, it's quite common to serve pages for > different fqdn's off the same ip address and port. this is why it's > important for browsers to send a 'Host:' header. And the comment I made earlier is that HTTP did not initially support this. The only way to indicate different sets of web pages used to be by looking at the IP address used to get to the server, where a shared hosting server had to have multiple IP addresses. One of the enhancements to HTTP when it was brought to the IETF was to get the target FQDN into HTTP, itself, so that HTTP did not have to rely on the lower layers to provide such multiplexing information. > but i'm unsure why we're talking about this. the purpose of the > specification is to define the protocol, not to provide a software > architecture or place limits on the deployment of software which > implements the virtual world. Correct. And I too always like to make sure folks don't confuse software issues with protocol architecture. So, indeed, I mean to be talking strictly about protocol architecture, here, not how it is implemented in software. > if we use the term "network host" in an > inappropriate way, that implies that a network host MUST deploy > software that implements one and only one revision of the OGP By 'revision' do you mean protocol version number or do you mean executing one or multiple instances of it, or something else? (I'm used to 'revision' to apply to editing, but suspect that's not what you mean here.) > to summarize my position... there's nothing in 2616 or 2396 that > addresses the issue as to whether it is a violation of the protocol to > run an HTTP responder off a port other than port 80. what's changed > that we now require such verbiage in draft charters? I'm not talking about port numbers. I guess the implication of the issue I am raising -- for those cases where OGP is running over HTTP -- is whether a user can access different (and independent) VW/grids when coming to the same IP address and TCP port number? If so, how does the server know which is intended? >> For example, by supporting different domain names an the exchange details of >> protocol, a single host can run different, independent web or email >> services.[1] > > are you implying that software that implements HTTP and XMPP, each of > which use a destination address is somehow incapable of using that > address? i'm very, very confused here. the OGP data formats and > protocol flows define the contents of messages and a scheme for using > HTTP URIs to resolve the network host and port to send messages to. > you are intimating that this is not sufficient, but give examples of > deprecated revisions of HTTP and SMTP. First, note the embedded reliance on web details. This is an example of what I suspect is the reality, that OGP is a value-add service of the web, tied to HTTP, etc. Not "transport independent". Second, you are describing the name-to-address resolution method by which a client gets to a server. Whereas I'm talking about the ability of the server to know which name was used, since the name-to-address mapping done here is a many-to-one mechanism. > OGP is not HTTP. nor is OGP SMTP. OGP is not XMPP. > > if you are deploying software that implements OGP, and that software > supports multiple, distinct virtual worlds that do not share > information. you should make sure that the protocol endpoints you > publish are sufficiently contextualized to be able to distinguish > which distinct virtual world the endpoint exposes an interface for. The question is what establishes that context? Does it require using information from the lower (transport) layers or is it independent of transport? If it uses information from the lower layers, then it is tied to a specific transport. > OGP is different from HTTP, however, in that it makes extensive use of > capabilities. capabilities are requested through interaction with a > single service URL (like the login URL defined in the auth / service > initiation draft.) but the concept is similar: the IP address of the > message destination by itself is insufficient to route the message to > the logical / conceptual entities responsible for processing the > message. It occurs to me that I don't know of any capability-based security mechanism having previously been deployed on the Internet. There's probably a red flag needed here, for due diligence. >> In reading the draft charter, I also had wondered about the use of "the" and >> level of interoperability being sought. The web, email, X.500 and the DNS >> are examples of having a single integrated service. For email, there is an >> acknowledgment of other services, by virtue of having "gateways" in the >> model, but they are entirely secondary to email technical work. The core >> model is a single integrated service. And that's the usual approach for >> Internet protocols. > > hmm.. the revision of the x.500 spec i worked on made it clear that an > entities would be explicitly allowed to have private directories and > would not be REQUIRED to integrate to the ill founded international > DIT. No not required, but as with the earlier X.400 work, out of which the X.500 effort developed, a single, global infrastructure was the intent. >> But it makes sense that virtual worlds would need to support multiple, >> INDEPENDENT worlds as discrete instances that do not interoperate. (One >> could imagine adding some ability to interoperate later, I guess, but I also >> suspect it would be hugely distracting to make it a goal now.) > > mmm.. i would have to argue against that. or at least encourage it's > discussion in the MMOX email list. I think there are levels of discussion to have about this. The first is being clear about what this issue means and that it is a relatively fundamental service design characteristic (or limitation). The second is what specific choice to make for OGP. I am trying to pursue the former and wasn't (yet) offering an opinion on the latter. > OGPX is intended to be a working group that focuses on protocol for > virtual worlds that share a common set of features: centralized > simulation instead of co-simulation, avatars being in one place at one > time, etc. So an organization that wants to use OGP for a company-internal service won't be able to do it, except perhaps by some lower-layer trick that probably won't work if the organization uses a cloud environment on the Net? Their service must be integrated into the global service? >>> when the OGP specifications use the term "the virtual world" it is >>> assumed they are talking about THE virtual world under discussion to >>> differentiate it from other virtual worlds that might exist. >> As minor as it might seem, changing the text to say "a" rather than "the" >> could also help clarify things, since it moves the entire charter's text >> over to the perspective that there is more than one and that the work >> defined by the charter is for a capability that provides a common way to >> deal with each of multiple instances, albeit separately. > > aha. so change ... > to ... > ??? possibly. >>> note that this usage is in keeping with several previous standards >>> efforts. X.500, for instance, describes "the directory" yet it is not >>> assumed that there will be a singleton instance of a directory. this >> Actually, that is exactly what it means, as I noted above.[2] Internet >> protocols usually define a single technical service, but with independent >> /administration/. Here you are defining multiple services that have a wall >> between them. > > again. as a participant in the X.500 / X.509 / PEM fiasco, and > implementer of those specs, it always seemed to me the specs allowed > the use of an independent DIT. that being said, if you chose to not > configure your software to add some type of differentiator at the top > of your tree, you could get very, very confused, very, very easily. > > i would argue also that even DNS does not REQUIRE that you point to > the same roots, it's just that it's CONSIDERABLY less useful if you > don't. More importantly, the DNS, itself, does not provide a way of knowing what root you point to. That decision is outside of the DNS protocol. Over the years, some common tricks have developed for accomplishing this, but again, they are not in the DNS architecture itself. That's because the DNS presumes global integration for ALL DNS entries. This really is a fundamental design issue for a protocol: does it have direct support for private name-spaces and services or does it assume complete, global integration? (in fact, the last rev of bind/named i looked at included the > IP addresses of the roots in a hints file.) hmm.. now that people are > getting serious about DNSSEC again, it might even be a discussion > that's not completely self-indulgent. but that's more of a discussion > to have over coffee / alcohol / food. > > so with respect to virtual worlds, let me say, "point well taken" and > run off and modify some draft charter language. Ack. tnx. > cool. i think we have two competing forces at work here. on one side > we have the requirement that the draft charter be clear, but on the > other is the requirement that it not define the space so well that the > current participants are the only ones who can participate. +1 > i think i understand what you're getting at now and have no problems > with clarifying language. BUT, we've already removed the list of > features that differentiate OGP virtual worlds from other virtual > worlds from the charter at your request. OK. Now I'm confused again: I did? Which list? i am beginning to get VERY > worried that we will soon be back at MMOX. I promise you that I, at least, have much, much more narrow focus for the chartering exercise. > i think i can speak for John Hurliman and David Lavine when i say, "we > are all about incremental enhancement." Did you start out being all about it, or did you come to it... incrementally? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dwl@us.ibm.com Sat Jul 25 07:27: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 CCC733A6967; Sat, 25 Jul 2009 07:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.093 X-Spam-Level: X-Spam-Status: No, score=-5.093 tagged_above=-999 required=5 tests=[AWL=0.905, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_75=0.6, 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 KYzgjhBy5fin; Sat, 25 Jul 2009 07:27:13 -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 AF7713A69FE; Sat, 25 Jul 2009 07:27:13 -0700 (PDT) Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e3.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n6PE82QU032715; Sat, 25 Jul 2009 10:08:02 -0400 Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n6PEDurv164094; Sat, 25 Jul 2009 10:13:57 -0400 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id n6PEDu3v007375; Sat, 25 Jul 2009 10:13:56 -0400 Received: from d01ml605.pok.ibm.com (d01ml605.pok.ibm.com [9.56.227.91]) by d01av05.pok.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id n6PEDuwf007372; Sat, 25 Jul 2009 10:13:56 -0400 In-Reply-To: <4A6AB9C0.6090109@dcrocker.net> References: <4A686B0C.9040802@dcrocker.net> <3a880e2c0907240659t57b8ba4ajd0b9078e2a3ee638@mail.gmail.com> <4A6AB9C0.6090109@dcrocker.net> To: dcrocker@bbiw.net MIME-Version: 1.0 X-KeepSent: A90FF98C:E6696759-852575FE:004D7662; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 Message-ID: From: David W Levine Date: Sat, 25 Jul 2009 10:13:55 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5|December 05, 2008) at 07/25/2009 10:13:55, Serialize complete at 07/25/2009 10:13:55 Content-Type: multipart/alternative; boundary="=_alternative 004E2E2F852575FE_=" Cc: Infinity Linden , Meadhbh Siobhan , ogpx@ietf.org, ogpx-bounces@ietf.org, dcrocker@bbiw.net Subject: Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds 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, 25 Jul 2009 14:27:14 -0000 This is a multipart message in MIME format. --=_alternative 004E2E2F852575FE_= Content-Type: text/plain; charset="US-ASCII" > > > i think i can speak for John Hurliman and David Lavine when i say, "we > > are all about incremental enhancement." > > Did you start out being all about it, or did you come to it... incrementally? > > > d/ > > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net > > The epigenesis of the OGPX work was Linden Lab's desire to re-structure their internal architecture to allow a scalable architecture. They realized that what they were going to do would give them a chance to actually define the interoperability points at the same time. Since Linden runs a multi-thousand server deployment, one of the earliest design points was the ability to move stepwise from the current legacy model to the next generation architecture. OpenSim is structured as a base platform with a set of extensions, such that one can create multiple diverse systems from the core parts. Factored interfaces, extensability and incremental change is pretty deep in the DNA of the work. - David W. Levine ~ Zha Ewry (In Second Life) --=_alternative 004E2E2F852575FE_= Content-Type: text/html; charset="US-ASCII"
>
> > i think i can speak for John Hurliman and David Lavine when i say, "we
> > are all about incremental enhancement."
>
> Did you start out being all about it, or did you come to it... incrementally?
>
>
> d/
>
> --
>
>    Dave Crocker
>    Brandenburg InternetWorking
>    bbiw.net
>
>
The epigenesis of the OGPX work was Linden Lab's desire to re-structure their internal architecture to allow a scalable architecture. They realized that what they were going to do would give them a chance to actually define the interoperability points at the same time. Since Linden runs a multi-thousand server deployment, one of the earliest design points was the ability to move stepwise from the current legacy model to the next generation architecture. OpenSim is structured as a base platform with a set of extensions, such that one can create multiple diverse systems from the core parts. Factored interfaces, extensability and incremental change is pretty deep in the DNA of the work.

- David W. Levine
~ Zha Ewry (In Second Life)
--=_alternative 004E2E2F852575FE_=-- From dhc@dcrocker.net Sun Jul 26 14:26: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 1732F28C124 for ; Sun, 26 Jul 2009 14:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 awcFv7QBephg for ; Sun, 26 Jul 2009 14:26:45 -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 AD10328C11F for ; Sun, 26 Jul 2009 14:26:44 -0700 (PDT) Received: from [10.43.1.48] ([77.241.97.116]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6QLQZcB001318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 26 Jul 2009 14:26:43 -0700 Message-ID: <4A6CC9F2.3040502@dcrocker.net> Date: Sun, 26 Jul 2009 23:26:10 +0200 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: ogpx@ietf.org 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, 26 Jul 2009 14:26:43 -0700 (PDT) Subject: [ogpx] the term 'grid' 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, 26 Jul 2009 21:26:46 -0000 Folks, A comment from a colleague, this evening, prompted me to do some searching, onlyu to discover that the word 'grid' is part of the "cloud computing" world, apparently with both some precise meaning and some pervasive misunderstanding: Since the OGPX work really has nothing to do with cloud computing and is an entirely domain of discourse, it could be confusing to use a term that is already entrenched in this neighboring discipline. Not sure what alternative to suggest, but though it worth raising a flag about the word 'grid'. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From missannotoole@yahoo.com Sun Jul 26 14:37:41 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 D69FF3A6BED for ; Sun, 26 Jul 2009 14:37:41 -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 OW0FbeDahUES for ; Sun, 26 Jul 2009 14:37:41 -0700 (PDT) Received: from web59102.mail.re1.yahoo.com (web59102.mail.re1.yahoo.com [66.196.101.13]) by core3.amsl.com (Postfix) with SMTP id C61DC3A6BE4 for ; Sun, 26 Jul 2009 14:37:40 -0700 (PDT) Received: (qmail 89506 invoked by uid 60001); 26 Jul 2009 21:37:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1248644259; bh=dxzpQAzS3JP2xzBKYfsyfVnUVRonzTflqcV3bTOmBo8=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=vzmzfdjeK1yf+O/Nbgj1xoYnCfZWzgtSN0K3JtInFVdZOl4f59Q37GvSqWbzRdu912WmiepdJXV5LYPrOZ+i6sRmEP9H6AnfKNHZuRiBJ4VWpZadv580zaIjYz+22buzS/mCg3KE1HjyVdd7KQG7TPwXAT6cWLyMMI2CfJ6Vcyo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=xAiPpJTVS22HZ160fnxYBzYL24sXdAFnw/QUznPFQwuZDYd2BP9UXeQu39EYo66g5a3JVVm6YXVlm6p39kbOaCUKWPVvlIEbWgjaclFEi+B9Hqsc9kZrabrHhf5hV2ASINztie+aL1J/q77EJpq101qdy4LlEBDpszJrsBpsYXY=; Message-ID: <127409.88846.qm@web59102.mail.re1.yahoo.com> X-YMail-OSG: b46cyyQVM1k2MgcK4xGVTky1fggn9jlvtAZPFqYNDEynoFzCayGGveSELnJlo.vjdDJFr.XdvOODfzh965Wnn8_nEmid4dTkVHTVMXETQcJgFXbDHP0WzqYgaI67lDEzpMyy6ZSWGh.j_pZkGEnZagIFpzlT0sHyZVQlF.1VBwapvNZuUyGH6v.K_n8VyhRTtvYTwlN58EGTi3ORpkmrznEeOcBvle03MAC_VRSV8VgXHaCh6Z1fFC5tjFE77I0KBqb_OhEKlcE1iC3rgHDuPW8ChEYLWlkamrCScBhPuo.IFMwx77E- Received: from [173.170.98.145] by web59102.mail.re1.yahoo.com via HTTP; Sun, 26 Jul 2009 14:37:39 PDT X-Mailer: YahooMailRC/1358.22 YahooMailWebService/0.7.338.1 References: <4A6CC9F2.3040502@dcrocker.net> Date: Sun, 26 Jul 2009 14:37:39 -0700 (PDT) From: Ann Otoole To: ogpx@ietf.org In-Reply-To: <4A6CC9F2.3040502@dcrocker.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-640808033-1248644259=:88846" 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: Sun, 26 Jul 2009 21:37:41 -0000 --0-640808033-1248644259=:88846 Content-Type: text/plain; charset=us-ascii Planet? System? Galaxy? Universe? Dimension? I look at each grid as a planet. I took the Second Life Grid and put it on a planet for a picture: http://www.annotoole.com/mylittleworld.png If each "grid" were a planet and similar planets that had trusted interop were "planetary systems" then non interoperable "planetary systems" (in of themselves interoperable would be in separate "galaxies". Another "dimension" would be a very interesting concept indeed. That is how I see it anyway. ________________________________ From: Dave CROCKER To: ogpx@ietf.org Sent: Sunday, July 26, 2009 5:26:10 PM Subject: [ogpx] the term 'grid' Folks, A comment from a colleague, this evening, prompted me to do some searching, onlyu to discover that the word 'grid' is part of the "cloud computing" world, apparently with both some precise meaning and some pervasive misunderstanding: Since the OGPX work really has nothing to do with cloud computing and is an entirely domain of discourse, it could be confusing to use a term that is already entrenched in this neighboring discipline. Not sure what alternative to suggest, but though it worth raising a flag about the word 'grid'. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ ogpx mailing list ogpx@ietf.org https://www.ietf.org/mailman/listinfo/ogpx --0-640808033-1248644259=:88846 Content-Type: text/html; charset=us-ascii
Planet? System? Galaxy? Universe? Dimension?

I look at each grid as a planet.

I took the Second Life Grid and put it on a planet for a picture: http://www.annotoole.com/mylittleworld.png

If each "grid" were a planet and similar planets that had trusted interop were "planetary systems" then non interoperable "planetary systems" (in of themselves interoperable  would be in separate "galaxies".

Another "dimension" would be a very interesting concept indeed.

That is how I see it anyway.



From: Dave CROCKER <dhc@dcrocker.net>
To: ogpx@ietf.org
Sent: Sunday, July 26, 2009 5:26:10 PM
Subject: [ogpx] the term 'grid'

Folks,

A comment from a colleague, this evening, prompted me to do some searching, onlyu to discover that the word 'grid' is part of the "cloud computing" world, apparently with both some precise meaning and some pervasive misunderstanding:

  <http://www.ibm.com/developerworks/web/library/wa-cloudgrid/>

Since the OGPX work really has nothing to do with cloud computing and is an entirely domain of discourse, it could be confusing to use a term that is already entrenched in this neighboring discipline.

Not sure what alternative to suggest, but though it worth raising a flag about the word 'grid'.

d/
--
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx

--0-640808033-1248644259=:88846-- From carlo@alinoe.com Sun Jul 26 15:42: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 3C1DA3A67E2 for ; Sun, 26 Jul 2009 15:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.13 X-Spam-Level: X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[AWL=0.300, 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 BdLFSdD1kizf for ; Sun, 26 Jul 2009 15:42:35 -0700 (PDT) Received: from viefep17-int.chello.at (viefep17-int.chello.at [62.179.121.37]) by core3.amsl.com (Postfix) with ESMTP id D22EF3A67D7 for ; Sun, 26 Jul 2009 15:42:34 -0700 (PDT) Received: from edge02.upc.biz ([192.168.13.237]) by viefep17-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090726224207.VAKY14607.viefep17-int.chello.at@edge02.upc.biz>; Mon, 27 Jul 2009 00:42:07 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge02.upc.biz with edge id Lmi51c0460FlQed02mi60L; Mon, 27 Jul 2009 00:42:07 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MVCR2-0000hQ-6i; Mon, 27 Jul 2009 00:43:16 +0200 Date: Mon, 27 Jul 2009 00:43:16 +0200 From: Carlo Wood To: Ann Otoole Message-ID: <20090726224316.GA2109@alinoe.com> References: <4A6CC9F2.3040502@dcrocker.net> <127409.88846.qm@web59102.mail.re1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <127409.88846.qm@web59102.mail.re1.yahoo.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ogpx@ietf.org 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: Sun, 26 Jul 2009 22:42:36 -0000 Parcel Sim / Region Land / Continent / Island World (grid) (/ Solar system) Galaxy (OGP connected Worlds) When not TP is possible, it would be a different Galaxy. I'm in favour of changing the name World --> Galaxy, and grid --> World. That would also take away concerns raised about the phrase in the draft "One world", since "One galaxy" implies a lot less that each World has the same rules (ToS). -- Carlo Wood From infinity@lindenlab.com Sun Jul 26 22:02: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 9D8E73A6BB6 for ; Sun, 26 Jul 2009 22:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.857 X-Spam-Level: X-Spam-Status: No, score=-1.857 tagged_above=-999 required=5 tests=[AWL=0.120, 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 c2wdTA6nMk8z for ; Sun, 26 Jul 2009 22:02:57 -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 81DFC3A6B92 for ; Sun, 26 Jul 2009 22:02:57 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c37so1428699anc.4 for ; Sun, 26 Jul 2009 22:02:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.43.10 with SMTP id q10mr7753812anq.125.1248670975923; Sun, 26 Jul 2009 22:02:55 -0700 (PDT) In-Reply-To: <4A6CC9F2.3040502@dcrocker.net> References: <4A6CC9F2.3040502@dcrocker.net> Date: Mon, 27 Jul 2009 07:02:55 +0200 Message-ID: <3a880e2c0907262202v7e8ada15gbc857751fa11400e@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] 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, 27 Jul 2009 05:02:58 -0000 thanks for bringing this up, dave. the IBM developer support article you reference and other references indicate that grid computing is "a form of distributed computing ... composed of a cluster of networked loosely coupled computers acting in concert to perform very large tasks." (i found that definition at the wikipedia and another IBM developer facing document) virtual worlds used for interoperability testing between Second Life and OpenSimulator were implemented by.. "a cluster of networked, loosely coupled computers acting in concert to perform a large task" (that large task is the simulation of the virtual world.) So the "grid" in Open Grid Protocol is accurate; it is a protocol intended to be deployed on a grid. confusing matters further, Oracle's developer support organization defines "grid computing" to be largely similar to what IBM developer support calls "cloud computing." Krauter and Maheswaran in the proceedings of the 1st IEEE/ACM International Workshop on Grid Compuing defines "grid computing" as... "a grid is a computing and data handling virtual system formed by aggregating the diverse services provided by diverse resources to synthesize problem solving environments." ( http://www.gridcomputing.org/grid2000/book/19710064.ps ) i'm not sure this rises to the definition of a "precise meaning." instead, it seems like there is general agreement that "grid computing" involves a loosely coupled collection of distributed hosts working together on the same or related problems. this is a good definition of the architecture we explicitly support with OGP. also... historically... the term "grid" has been used among the OGP interoperability investigators to define the collection of distributed systems which implement the virtual world under simulation. On Sun, Jul 26, 2009 at 11:26 PM, Dave CROCKER wrote: > Folks, > > A comment from a colleague, this evening, prompted me to do some searchin= g, > onlyu to discover that the word 'grid' is part of the "cloud computing" > world, apparently with both some precise meaning and some pervasive > misunderstanding: > > =A0 > > Since the OGPX work really has nothing to do with cloud computing and is = an > entirely domain of discourse, it could be confusing to use a term that is > already entrenched in this neighboring discipline. > > Not sure what alternative to suggest, but though it worth raising a flag > about the word 'grid'. > > d/ > -- > > =A0Dave Crocker > =A0Brandenburg InternetWorking > =A0bbiw.net > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > From morgaine.dinova@googlemail.com Sun Jul 26 22:46: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 0D28C3A698F for ; Sun, 26 Jul 2009 22:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.634 X-Spam-Level: X-Spam-Status: No, score=-0.634 tagged_above=-999 required=5 tests=[AWL=0.742, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_75=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 9xGS1cY+qKAu for ; Sun, 26 Jul 2009 22:46:29 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 2BBE03A6950 for ; Sun, 26 Jul 2009 22:46:28 -0700 (PDT) Received: by ewy26 with SMTP id 26so2916971ewy.37 for ; Sun, 26 Jul 2009 22:46:27 -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:cc:content-type; bh=VEEYCE7sjZvsQzPep6b+nsGcSh/43K/dI6/C9b88kFI=; b=Rri9W9ifUck1XFPRbjNWZqMQE/R236/7kzhYH35DKskw4gZA3gmo2dpcFOyXcPDk3u 7LcOZ53FYTOnE2Yo4E8mVt9XzTCkc1rLw1vFYpBU0EVbOcQdZcD88HExG9ZrHFtQNX94 ieNuSN2n9tFoZh9rqbY3bxQt4H7k78f6MswjA= 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 :cc:content-type; b=vVT7ZI+tHBNoJTeKen229DbhNo/W/bJjGvCeSCX25bf8Z3voSAN7eSEgqOruqmVFUp v6g0czefTfsGGeesYGHJeTaT07mJDn4YeoEzOiKfm6azU1a2dpX7N4/2V3pMaQiprBN8 33en373xX+tiaClpqx9lmUmGkkJzJYMBAVqQ0= MIME-Version: 1.0 Received: by 10.216.52.78 with SMTP id d56mr1569383wec.143.1248673580729; Sun, 26 Jul 2009 22:46:20 -0700 (PDT) In-Reply-To: References: <4A686B0C.9040802@dcrocker.net> <3a880e2c0907240659t57b8ba4ajd0b9078e2a3ee638@mail.gmail.com> <4A6AB9C0.6090109@dcrocker.net> Date: Mon, 27 Jul 2009 06:46:20 +0100 Message-ID: From: Morgaine To: David W Levine Content-Type: multipart/alternative; boundary=0016e6dbe6dc3ad2b3046fa97947 Cc: ogpx@ietf.org Subject: Re: [ogpx] OGPX Charter+Intro ambiguity in Virtual World vs Virtual Worlds 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, 27 Jul 2009 05:46:31 -0000 --0016e6dbe6dc3ad2b3046fa97947 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sat, Jul 25, 2009 at 3:13 PM, David W Levine wrote: > > Since Linden runs a multi-thousand server deployment, one of the earliest > design points was the ability to move stepwise from the current legacy model > to the next generation architecture. OpenSim is structured as a base > platform with a set of extensions, such that one can create multiple diverse > systems from the core parts. David, that's an interesting observation, and very pertinent to the issue I raised about multiple interoperating virtual worlds versus a single world. There is more to this than just a choice of phrase, and Opensim provides a good example. Opensim-based grids and Hypergrid-connected Opensim worlds have the ability to run a multiplicity of interop protocols, with OGP and SL-legacy being just a subset. All such interworking code is being progressively refactored into alternative modules that sit side by side in Opensim, with new modules expected to appear in the future, exactly as you say. It is a modular and extensible framework by design. What this means for the topology and character of future Opensim-based worlds is that we should expect much diversity. In particular, an Opensim world that communicates with SL through OGP may be *simultaneously*connected to some other world via MXP, Hypergrid, or some other protocol. This diversity in protocols is very likely to result in world features in Opensim worlds that are quite foreign to SL for example, as has already happened with realXtend. >From this it seems a safe conclusion that two virtual worlds that employ OGP for interop between them are often going to be very different to each other. The only commonality necessary is that they can both speak the same language of OGP, which after all is just a communications protocol and not a world specification. To speak of commonality of worlds is just not appropriate in this context, since it would be purely coincidental. We don't have one world in any real sense of the phrase -- what we have is one protocol, and multiple worlds will interoperate by speaking it, no matter how else they differ. Many factors encourage and *require* a model of multiple separate but interoperating worlds: - product differentiation as a part of business, - strong separation of worlds as a part of security, - world diversity as a part of normal cultural variety, - worlds uniqueness stemming from human creativity and sheer eccentricity, - sovereignty of worlds as a part of politics, and relatedly, - the essential demarcation of legal jurisdictions. Given the above, it is quite wrong that the concept of multiple interoperating virtual worlds has been dropped in favour of conjuring up a fictitious "single world" spanning the endpoints. This is particularly so when that cute phrase serves no useful purpose in the protocol and confusingly conjures up a protocol entity that does not actually exist. Indeed, it is a dangerous turn of phrase, and it is likely to result in legal issues when differing legal requirements at two communicating OGP endpoints find themselves applying to the "one world" of the protocol. I believe that the "one world" language is an unnecessary complication with no benefit to protocol users nor to understanding, and should be omitted. In answer to my earlier post on this subject, "one world" has been portrayed by some as just a literary element with no strong or binding meaning. Well if that is so then the case for removal from the drafts is strengthened even further, since an Internet standard does not benefit from superfluous literary adornments. Morgaine. On Sat, Jul 25, 2009 at 3:13 PM, David W Levine wrote: > > > > > > i think i can speak for John Hurliman and David Lavine when i say, "we > > > are all about incremental enhancement." > > > > Did you start out being all about it, or did you come to it... > incrementally? > > > > > > d/ > > > > -- > > > > Dave Crocker > > Brandenburg InternetWorking > > bbiw.net > > > > > The epigenesis of the OGPX work was Linden Lab's desire to re-structure > their internal architecture to allow a scalable architecture. They realized > that what they were going to do would give them a chance to actually define > the interoperability points at the same time. Since Linden runs a > multi-thousand server deployment, one of the earliest design points was the > ability to move stepwise from the current legacy model to the next > generation architecture. OpenSim is structured as a base platform with a set > of extensions, such that one can create multiple diverse systems from the > core parts. Factored interfaces, extensability and incremental change is > pretty deep in the DNA of the work. > > - David W. Levine > ~ Zha Ewry (In Second Life) > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > > --0016e6dbe6dc3ad2b3046fa97947 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Jul 25, 2009 at 3:13 PM, David W Levine = <dwl@us.ibm.com&= gt; wrote:

Since Linden runs a multi-thousand server deployment, one of the earliest design points was the ability to move stepwise from the current legacy model to the next generation architec= ture. OpenSim is structured as a base platform with a set of extensions, such that one can create multiple diverse systems from the core parts.


David, that's an interesting observation, a= nd very pertinent to the issue I raised about multiple interoperating virtu= al worlds versus a single world.=A0 There is more to this than just a choic= e of phrase, and Opensim provides a good example.

Opensim-based grids and Hypergrid-connected Opensim worlds have the abi= lity to run a multiplicity of interop protocols, with OGP and SL-legacy bei= ng just a subset.=A0 All such interworking code is being progressively refa= ctored into alternative modules that sit side by side in Opensim, with new = modules expected to appear in the future, exactly as you say.=A0 It is a mo= dular and extensible framework by design.

What this means for the topology and character of future Opensim-based = worlds is that we should expect much diversity.=A0 In particular, an Opensi= m world that communicates with SL through OGP may be simultaneously = connected to some other world via MXP, Hypergrid, or some other protocol.= =A0 This diversity in protocols is very likely to result in world features = in Opensim worlds that are quite foreign to SL for example, as has already = happened with realXtend.

From this it seems a safe conclusion that two virtual worlds that emplo= y OGP for interop between them are often going to be very different to each= other.=A0 The only commonality necessary is that they can both speak the s= ame language of OGP, which after all is just a communications protocol and = not a world specification.=A0 To speak of commonality of worlds is just not= appropriate in this context, since it would be purely coincidental.=A0 We = don't have one world in any real sense of the phrase -- what we have is= one protocol, and multiple worlds will interoperate by speaking it, no mat= ter how else they differ.

Many factors encourage and require a model of multip= le separate but interoperating worlds:

  • product differentiati= on as a part of business,
  • strong separation of worlds as a part of = security,
  • world diversity as a part of normal cultural variety,
  • worlds un= iqueness stemming from human creativity and sheer eccentricity,
  • sov= ereignty of worlds as a part of politics, and relatedly,
  • the es= sential demarcation of legal jurisdictions.

Given the above, it is quite wrong that the concept of multiple in= teroperating virtual worlds has been dropped in favour of conjuring up a fi= ctitious "single world" spanning the endpoints.=A0 This is partic= ularly so when that cute phrase serves no useful purpose in the protocol an= d confusingly conjures up a protocol entity that does not actually exist.
Indeed, it is a dangerous turn of phrase, and it is likely to result in= legal issues when differing legal requirements at two communicating OGP en= dpoints find themselves applying to the "one world" of the protoc= ol.=A0 I believe that the "one world" language is an unnecessary = complication with no benefit to protocol users nor to understanding, and sh= ould be omitted.

In answer to my earlier post on this subject, "one world" has= been portrayed by some as just a literary element with no strong or bindin= g meaning.=A0 Well if that is so then the case for removal from the drafts = is strengthened even further, since an Internet standard does not benefit f= rom superfluous literary adornments.


Morgaine.









On Sat, Jul 25, 2009 at 3:13 PM, David W Levine = <dwl@us.ibm.com> wrote:<= br>

>
> > i think i can speak for John Hurliman and David Lavine when i say, "we
> > are all about incremental enhancement."
>
> Did you start out being all about it, or did you come to it... increme= ntally?
>
>
> d/
>
> --
>
> =A0 =A0Dave Crocker
> =A0 =A0Brandenburg InternetWorking
> =A0 =A0bbiw.net
>
>
The epigenesis of the OGPX work was Linden Lab's desire to re-structure their internal architecture to allow a scalable architecture. They realized that what they were going to do would give them a chance to actually define the interoperability points at the same time. Since Linden runs a multi-tho= usand server deployment, one of the earliest design points was the ability to move stepwise from the current legacy model to the next generation architec= ture. OpenSim is structured as a base platform with a set of extensions, such that one can create multiple diverse systems from the core parts. Factored interfaces, extensability and incremental change is pretty deep in the DNA of the work.

- David W. Levine
~ Zha Ewry (In Second Life)

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


--0016e6dbe6dc3ad2b3046fa97947-- From dhc@dcrocker.net Mon Jul 27 00:42:41 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 7C4D328C169 for ; Mon, 27 Jul 2009 00:42:41 -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 U25ddeU9SEH8 for ; Mon, 27 Jul 2009 00:42:40 -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 2F17D28C134 for ; Mon, 27 Jul 2009 00:42:40 -0700 (PDT) Received: from [130.129.87.235] (dhcp-57eb.meeting.ietf.org [130.129.87.235] (may be forged)) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n6R7gWCq005911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Jul 2009 00:42:39 -0700 Message-ID: <4A6D5A4E.4000602@dcrocker.net> Date: Mon, 27 Jul 2009 09:42:06 +0200 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Infinity Linden References: <4A6CC9F2.3040502@dcrocker.net> <3a880e2c0907262202v7e8ada15gbc857751fa11400e@mail.gmail.com> In-Reply-To: <3a880e2c0907262202v7e8ada15gbc857751fa11400e@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]); Mon, 27 Jul 2009 00:42:39 -0700 (PDT) Cc: ogpx@ietf.org Subject: Re: [ogpx] the term 'grid' 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, 27 Jul 2009 07:42:41 -0000 > So the "grid" in Open Grid Protocol is accurate; it is a protocol > intended to be deployed on a grid. Yes and no. It is a particular instance of the construct. Except that the term is really tied to an implementation model, whereas OGPX is quite explicitly not. So while it probably really is a legitimate instance, there is a plausible argument that it isn't. Fundamentally, cloud computing is remote shared service hosting. A long-standing, low-level service that comes into vogue every 15 years or so. This is vastly different than the semantics of "virtual worlds". That is, the term is tied to details that seem not to apply here. The question is whether it might cause confusion in folks in the general Internet technical community. I tend to be in favor of labels that work hard to be correctly meaningful and relevant to outsiders and to avoid confusion. It is usually a challenge to get the right balance. I initially thought that the choice of 'grid' was quite quite a good choice, until coming across its use in the cloud world. There is a tendency to use labels that are refer to a mechanical point at too low a level or to be too general. The fact that the cloud world not only uses 'grid' but apparently has some confusion about its use is what prompted me to raise the flag. > i'm not sure this rises to the definition of a "precise meaning." > instead, it seems like there is general agreement that "grid > computing" involves a loosely coupled collection of distributed hosts > working together on the same or related problems. this is a good > definition of the architecture we explicitly support with OGP. > > also... historically... the term "grid" has been used among the OGP > interoperability investigators to define the collection of distributed > systems which implement the virtual world under simulation. Exactly the issue: It invokes implementation rather than semantic concepts. In looking at the the postings offering alternative suggestions, I was drawn to 'Region' since it is a core term already in the existing documents, and it refers to the entity/location that instantiates a world itself. The word "Region" does not have any substantial history in this realm of computing or networking; so collisions and confusion won't happen. If I am understanding the existing documents and the goal of the current effort, it is targeting access to regions. Region Access Protocol (RAP) seems like a plausible choice. No doubt there are others. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dyerbrookme@juno.com Wed Jul 29 21:08:18 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 7545128C12B for ; Wed, 29 Jul 2009 21:08:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[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 ka4s2oPDRH7i for ; Wed, 29 Jul 2009 21:08:17 -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 9E6E128C127 for ; Wed, 29 Jul 2009 21:08:17 -0700 (PDT) X-UOL-TAGLINE: true Received: from outbound-bu1.vgs.untd.com (webmail02.vgs.untd.com [10.181.12.142]) by smtpout02.vgs.untd.com with SMTP id AABFHCHFHA2VQ9GA for (sender ); Wed, 29 Jul 2009 21:08:07 -0700 (PDT) X-UNTD-OriginStamp: ireJTaFtV8IZgEqY8qAucUz3kd483WdhKaAoAnbCYY0ssPQscFT0uw== Received: (from dyerbrookme@juno.com) by webmail02.vgs.untd.com (jqueuemail) id PNPLJ8A3; Wed, 29 Jul 2009 21:08:06 PDT Received: from [141.149.49.73] by webmail02.vgs.untd.com with HTTP: Thu, 30 Jul 2009 04:07:48 GMT X-Originating-IP: [141.149.49.73] Mime-Version: 1.0 From: "dyerbrookme@juno.com" Date: Thu, 30 Jul 2009 04:07:48 GMT To: dcrocker@bbiw.net X-Mailer: Webmail Version 4.0 Message-Id: <20090730.000748.17075.0@webmail02.vgs.untd.com> Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain; charset=ISO-8859-1 X-ContentStamp: 3:4:2610626986 X-MAIL-INFO: 1f7070f959c949b0f9a949c9b1c9c19505bd1010d510844444a444e5201d1000705959f19061e0c4e550e061c0 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 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: Thu, 30 Jul 2009 04:08:18 -0000 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 From josh@lindenlab.com Thu Jul 30 00:40: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 C83B528C133 for ; Thu, 30 Jul 2009 00:40:12 -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 75MMMv4SzP2n for ; Thu, 30 Jul 2009 00:40:11 -0700 (PDT) Received: from tammy.lindenlab.com (tammy.lindenlab.com [216.82.11.128]) by core3.amsl.com (Postfix) with ESMTP id 5533928C15A for ; Thu, 30 Jul 2009 00:39:33 -0700 (PDT) Received: from dhcp-1075.meeting.ietf.org (dhcp-1075.meeting.ietf.org [130.129.16.117]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 8439C3DBC06C for ; Thu, 30 Jul 2009 00:39:34 -0700 (PDT) Message-Id: From: Joshua Bell To: ogpx@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 30 Jul 2009 09:39:32 +0200 X-Mailer: Apple Mail (2.935.3) Subject: [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: Thu, 30 Jul 2009 07:40:12 -0000 A draft WG charter was discussed at the BOF, the text of which can be found here: http://www.ietf.org/proceedings/75/slides/ogpx-2.txt Our highest priority goal is to refine the charter. The BOF provided us with an excellent set of questions and issues to address. These have not yet been incorporated, and are listed below along with open questions. * We are looking for feedback in the form of specific changes to make to the proposed charter and rationale for the language used. * We have an explicit goal of submitting the charter within 2 weeks to the ISEG and IAB for approval. Necessary charter changes: 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? 2. Larry Masinter and Dave Crocker argued persuasively for a functional description of the protocol's uses. Rather than describe the protocol only in abstract terms, provide a non-exhaustive list of protocol effects. 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." 3. The text of the charter should have a clear list of working group deliverables. 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, Are there any deliverables missing? Have we covered the functional needs. When proposing additional deliverables, please describe them in sufficient detail to enable discussion. 4. A small number of key terms should be introduced and briefly described, especially any used in the functional description (#2, above). Suggestions for these terms include agent, avatar, user, region, asset, domain, service, resource, agent domain and region domain. Ultimately the list of terms to include will be derived from other parts of the charter to make it independent of other texts, but are there other terms that must be defined? 5. Should the working group investigate operational aspects of virtual worlds? If so, what language should be added to the charter? 6. "OGP" is not an appropriate name for the WG or protocol - "grid" is ambiguous. (Our usage plays off the double meaning of a square subdivision of regions, and a computing cluster, neither of which are expected to be explicit in the protocol.) Suggestions so far include: * "Region Access Protocol" (RAP) - captures region-based VW specificity * "Agent/Region Interaction Protocol" (ARIP) - highlights the active entities Are there any other suggestions, preferences, or vetos? Does the proposed protocol name need to be reflected in a revised Working Group name? Contrariwise, does the WG name need to be reflected in protocols it develops? (Strictly: "no" and "no", but in practice...?) Serious name suggestions which promote clever acronyms for future IETF sessions are encouraged. 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? 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. 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. 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. 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. 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? (This may affect the terminology used for #11.) From AVSHALOM@il.ibm.com Thu Jul 30 03:09: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 EBDFB3A69E1; Thu, 30 Jul 2009 03:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.133 X-Spam-Level: X-Spam-Status: No, score=-6.133 tagged_above=-999 required=5 tests=[AWL=0.465, 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 4GhHCtFZ8o4n; Thu, 30 Jul 2009 03:09:36 -0700 (PDT) Received: from mtagate4.de.ibm.com (mtagate4.de.ibm.com [195.212.29.153]) by core3.amsl.com (Postfix) with ESMTP id 442AD3A691E; Thu, 30 Jul 2009 03:09:20 -0700 (PDT) Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.14.3/8.13.8) with ESMTP id n6UA9451083660; Thu, 30 Jul 2009 10:09:04 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n6UA94aK2519214; Thu, 30 Jul 2009 12:09:04 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n6UA93AM032230; Thu, 30 Jul 2009 12:09:03 +0200 Received: from d12mc102.megacenter.de.ibm.com (d12mc102.megacenter.de.ibm.com [9.149.167.114]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n6UA936P032223; Thu, 30 Jul 2009 12:09:03 +0200 In-Reply-To: References: To: Joshua Bell MIME-Version: 1.0 X-KeepSent: 5205B798:BB06D18E-C2257603:003725F1; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5 December 05, 2008 From: Avshalom Houri Message-ID: Date: Thu, 30 Jul 2009 13:09:03 +0300 X-MIMETrack: Serialize by Router on D12MC102/12/M/IBM(Release 8.5|December 05, 2008) at 30/07/2009 13:09:03, Serialize complete at 30/07/2009 13:09:03 Content-Type: multipart/alternative; boundary="=_alternative 0037736DC2257603_=" 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: Thu, 30 Jul 2009 10:09:38 -0000 This is a multipart message in MIME format. --=_alternative 0037736DC2257603_= Content-Type: text/plain; charset="US-ASCII" What about VIP - Virtual-worlds Integration Protocol for a name? Thanks --Avshalom From: Joshua Bell To: ogpx@ietf.org Date: 30/07/2009 10:40 AM Subject: [ogpx] Next Steps for OGPX WG Charter Sent by: ogpx-bounces@ietf.org A draft WG charter was discussed at the BOF, the text of which can be found here: http://www.ietf.org/proceedings/75/slides/ogpx-2.txt Our highest priority goal is to refine the charter. The BOF provided us with an excellent set of questions and issues to address. These have not yet been incorporated, and are listed below along with open questions. * We are looking for feedback in the form of specific changes to make to the proposed charter and rationale for the language used. * We have an explicit goal of submitting the charter within 2 weeks to the ISEG and IAB for approval. Necessary charter changes: 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? 2. Larry Masinter and Dave Crocker argued persuasively for a functional description of the protocol's uses. Rather than describe the protocol only in abstract terms, provide a non-exhaustive list of protocol effects. 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." 3. The text of the charter should have a clear list of working group deliverables. 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, Are there any deliverables missing? Have we covered the functional needs. When proposing additional deliverables, please describe them in sufficient detail to enable discussion. 4. A small number of key terms should be introduced and briefly described, especially any used in the functional description (#2, above). Suggestions for these terms include agent, avatar, user, region, asset, domain, service, resource, agent domain and region domain. Ultimately the list of terms to include will be derived from other parts of the charter to make it independent of other texts, but are there other terms that must be defined? 5. Should the working group investigate operational aspects of virtual worlds? If so, what language should be added to the charter? 6. "OGP" is not an appropriate name for the WG or protocol - "grid" is ambiguous. (Our usage plays off the double meaning of a square subdivision of regions, and a computing cluster, neither of which are expected to be explicit in the protocol.) Suggestions so far include: * "Region Access Protocol" (RAP) - captures region-based VW specificity * "Agent/Region Interaction Protocol" (ARIP) - highlights the active entities Are there any other suggestions, preferences, or vetos? Does the proposed protocol name need to be reflected in a revised Working Group name? Contrariwise, does the WG name need to be reflected in protocols it develops? (Strictly: "no" and "no", but in practice...?) Serious name suggestions which promote clever acronyms for future IETF sessions are encouraged. 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? 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. 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. 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. 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. 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? (This may affect the terminology used for #11.) _______________________________________________ ogpx mailing list ogpx@ietf.org https://www.ietf.org/mailman/listinfo/ogpx --=_alternative 0037736DC2257603_= Content-Type: text/html; charset="US-ASCII" What about VIP - Virtual-worlds Integration Protocol for a name?

Thanks
--Avshalom


From: Joshua Bell <josh@lindenlab.com>
To: ogpx@ietf.org
Date: 30/07/2009 10:40 AM
Subject: [ogpx] Next Steps for OGPX WG Charter
Sent by: ogpx-bounces@ietf.org




A draft WG charter was discussed at the BOF, the text of which can be  
found here:

http://www.ietf.org/proceedings/75/slides/ogpx-2.txt

Our highest priority goal is to refine the charter. The BOF provided  
us with an excellent set of questions and issues to address. These  
have not yet been incorporated, and are listed below along with open  
questions.

* We are looking for feedback in the form of specific changes to make  
to the proposed charter and rationale for the language used.

* We have an explicit goal of submitting the charter within 2 weeks to  
the ISEG and IAB for approval.


Necessary charter changes:


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?


2. Larry Masinter and Dave Crocker argued persuasively for a  
functional description of the protocol's uses. Rather than describe  
the protocol only in abstract terms, provide a non-exhaustive list of  
protocol effects. 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."


3. The text of the charter should have a clear list of working group  
deliverables.

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,

Are there any deliverables missing? Have we covered the functional  
needs. When proposing additional deliverables, please describe them in  
sufficient detail to enable discussion.


4. A small number of key terms should be introduced and briefly  
described, especially any used in the functional description (#2,  
above). Suggestions for these terms include agent, avatar, user,  
region, asset, domain, service, resource, agent domain and region  
domain.

Ultimately the list of terms to include will be derived from other  
parts of the charter to make it independent of other texts, but are  
there other terms that must be defined?


5. Should the working group investigate operational aspects of virtual  
worlds? If so, what language should be added to the charter?


6. "OGP" is not an appropriate name for the WG or protocol - "grid" is  
ambiguous. (Our usage plays off the double meaning of a square  
subdivision of regions, and a computing cluster, neither of which are  
expected to be explicit in the protocol.) Suggestions so far include:

* "Region Access Protocol" (RAP) - captures region-based VW specificity
* "Agent/Region Interaction Protocol" (ARIP) - highlights the active  
entities

Are there any other suggestions, preferences, or vetos? Does the  
proposed protocol name need to be reflected in a revised Working Group  
name? Contrariwise, does the WG name need to be reflected in protocols  
it develops? (Strictly: "no" and "no", but in practice...?) Serious  
name suggestions which promote clever acronyms for future IETF  
sessions are encouraged.


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?


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.


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.


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.


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.


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?

(This may affect the terminology used for #11.)


_______________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx
--=_alternative 0037736DC2257603_=-- From carlo@alinoe.com Thu Jul 30 17:31: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 AF1D23A6A81 for ; Thu, 30 Jul 2009 17:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.28 X-Spam-Level: X-Spam-Status: No, score=-1.28 tagged_above=-999 required=5 tests=[AWL=0.150, 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 nIAiUVrvHORN for ; Thu, 30 Jul 2009 17:31:26 -0700 (PDT) Received: from viefep19-int.chello.at (viefep19-int.chello.at [62.179.121.39]) by core3.amsl.com (Postfix) with ESMTP id 772373A6A49 for ; Thu, 30 Jul 2009 17:31:25 -0700 (PDT) Received: from edge04.upc.biz ([192.168.13.239]) by viefep20-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090731003005.SBVR9817.viefep20-int.chello.at@edge04.upc.biz>; Fri, 31 Jul 2009 02:30:05 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge04.upc.biz with edge id NQW41c0120FlQed04QW5jQ; Fri, 31 Jul 2009 02:30:05 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MWg1u-0002ca-4N; Fri, 31 Jul 2009 02:31:26 +0200 Date: Fri, 31 Jul 2009 02:31:26 +0200 From: Carlo Wood To: Joshua Bell Message-ID: <20090731003126.GA9863@alinoe.com> References: 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] 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: Fri, 31 Jul 2009 00:31:26 -0000 On Thu, Jul 30, 2009 at 09:39:32AM +0200, 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? Someone once said: "Of course it's not working perfectly: this is the VERY first version of the Matrix". -- Carlo Wood From carlo@alinoe.com Thu Jul 30 17:59: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 035493A6B8A for ; Thu, 30 Jul 2009 17:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.33 X-Spam-Level: X-Spam-Status: No, score=-1.33 tagged_above=-999 required=5 tests=[AWL=0.100, 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 gJM6Yc6Hn-w2 for ; Thu, 30 Jul 2009 17:59:37 -0700 (PDT) Received: from viefep22-int.chello.at (viefep22-int.chello.at [62.179.121.42]) by core3.amsl.com (Postfix) with ESMTP id CB0F128C144 for ; Thu, 30 Jul 2009 17:59:27 -0700 (PDT) Received: from edge05.upc.biz ([192.168.13.212]) by viefep20-int.chello.at (InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP id <20090731005833.SNYR9817.viefep20-int.chello.at@edge05.upc.biz>; Fri, 31 Jul 2009 02:58:33 +0200 Received: from mail9.alinoe.com ([77.250.43.12]) by edge05.upc.biz with edge id NQyW1c01T0FlQed05QyXPw; Fri, 31 Jul 2009 02:58:33 +0200 X-SourceIP: 77.250.43.12 Received: from carlo by mail9.alinoe.com with local (Exim 4.69) (envelope-from ) id 1MWgTQ-00032A-5E; Fri, 31 Jul 2009 02:59:52 +0200 Date: Fri, 31 Jul 2009 02:59:52 +0200 From: Carlo Wood To: Joshua Bell Message-ID: <20090731005952.GB9863@alinoe.com> References: <20090731003126.GA9863@alinoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090731003126.GA9863@alinoe.com> User-Agent: Mutt/1.5.18 (2008-05-17) 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: Fri, 31 Jul 2009 00:59:38 -0000 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 -- Carlo Wood From dhc@dcrocker.net Fri Jul 31 21:10: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 E8F803A67EA for ; Fri, 31 Jul 2009 21:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.123, 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 vNLxudDga-PI for ; Fri, 31 Jul 2009 21:10:27 -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 BF2EC3A67AD for ; Fri, 31 Jul 2009 21:10:26 -0700 (PDT) Received: from [10.43.1.178] ([77.241.97.116]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n714AGmL014516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Jul 2009 21:10:23 -0700 Message-ID: <4A73C01F.6010600@dcrocker.net> Date: Sat, 01 Aug 2009 06:10:07 +0200 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Carlo Wood References: <20090731003126.GA9863@alinoe.com> <20090731005952.GB9863@alinoe.com> In-Reply-To: <20090731005952.GB9863@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]); Fri, 31 Jul 2009 21:10:24 -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: Sat, 01 Aug 2009 04:10:28 -0000 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.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From morgaine.dinova@googlemail.com Fri Jul 31 21:44: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 51A1F3A6AA3 for ; Fri, 31 Jul 2009 21:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.181 X-Spam-Level: X-Spam-Status: No, score=-1.181 tagged_above=-999 required=5 tests=[AWL=0.795, 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 am9nNYrpdNaT for ; Fri, 31 Jul 2009 21:44:35 -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 524B53A6B10 for ; Fri, 31 Jul 2009 21:44:15 -0700 (PDT) Received: by ewy2 with SMTP id 2so1847050ewy.43 for ; Fri, 31 Jul 2009 21:44:14 -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:cc:content-type; bh=BoGzeE3dPrTVdqrzpbo7C1n05GyqblFsC6Vf95gV1w0=; b=aITX42gr5m0ZjtoGc7nQ41ZcofjmGTnIr7q55eWBt0eiXBhPEHLMRlLvgPIe5FAztz P1k/UmBXl05r9YPsyQRC3mK6n0uEJy9avewGrdML4mSrqi8nSdNDxYi0XJAtlwcLZ1u5 MQjG6v3bIx4Fxtny5tTQ/gENLK1CfT5Y7Q2lM= 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 :cc:content-type; b=gEV2bizXgoDEL/OA0PVtj9hkpiHLOEymJELW2ugIKS9PAR3qcm/N05itqED6c00j9N 4DiQVWt0AKblEk7wbYj8A9a9tA8KkAJ3aC0jiQpNgMqkWkWt74yd/flIYgKIxi3Zmlm0 xkAS0tNLkUgedDST03VxErbQ/V6vRBHMcEDzI= MIME-Version: 1.0 Received: by 10.216.90.131 with SMTP id e3mr617964wef.69.1249101854440; Fri, 31 Jul 2009 21:44:14 -0700 (PDT) In-Reply-To: References: Date: Sat, 1 Aug 2009 05:44:14 +0100 Message-ID: From: Morgaine To: Joshua Bell Content-Type: multipart/alternative; boundary=0016e6dab171527f2304700d300d 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: Sat, 01 Aug 2009 04:44:37 -0000 --0016e6dab171527f2304700d300d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Thu, Jul 30, 2009 at 8:39 AM, Joshua Bell wrote: > > Necessary charter changes: > > 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? > Joshua, I've been looking at one particular aspect of how to define our problem space in such a way that it is concise and narrow enough to exclude the "interop all worlds" of MMOX, while at the same time flexible and broad enough to make it apply to more than just exact Second Life clones. In other words, how to define the catchment area such that OGP becomes a worthwhile protocol for more than just one company's goals. 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. That sounds to me like a very good basis for a charter upon which to build a protocol that satisfies the known goals of OGP as we have discussed for almost two years, while at the same time being in tune with the Mission Statement of the IETF in respect of wide deployment and interoperation on the Internet. I propose that the current charter be rephrased to make the above plain, because in its current form it is unnecessarily restrictive and inconsistent in its reference to virtual worlds. I can have a go at this myself if you like. Morgaine. On Thu, Jul 30, 2009 at 8:39 AM, Joshua Bell wrote: > A draft WG charter was discussed at the BOF, the text of which can be found > here: > > http://www.ietf.org/proceedings/75/slides/ogpx-2.txt > > Our highest priority goal is to refine the charter. The BOF provided us > with an excellent set of questions and issues to address. These have not yet > been incorporated, and are listed below along with open questions. > > * We are looking for feedback in the form of specific changes to make to > the proposed charter and rationale for the language used. > > * We have an explicit goal of submitting the charter within 2 weeks to the > ISEG and IAB for approval. > > > Necessary charter changes: > > > 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? > > > 2. Larry Masinter and Dave Crocker argued persuasively for a functional > description of the protocol's uses. Rather than describe the protocol only > in abstract terms, provide a non-exhaustive list of protocol effects. 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." > > > 3. The text of the charter should have a clear list of working group > deliverables. > > 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, > > Are there any deliverables missing? Have we covered the functional needs. > When proposing additional deliverables, please describe them in sufficient > detail to enable discussion. > > > 4. A small number of key terms should be introduced and briefly described, > especially any used in the functional description (#2, above). Suggestions > for these terms include agent, avatar, user, region, asset, domain, service, > resource, agent domain and region domain. > > Ultimately the list of terms to include will be derived from other parts of > the charter to make it independent of other texts, but are there other terms > that must be defined? > > > 5. Should the working group investigate operational aspects of virtual > worlds? If so, what language should be added to the charter? > > > 6. "OGP" is not an appropriate name for the WG or protocol - "grid" is > ambiguous. (Our usage plays off the double meaning of a square subdivision > of regions, and a computing cluster, neither of which are expected to be > explicit in the protocol.) Suggestions so far include: > > * "Region Access Protocol" (RAP) - captures region-based VW specificity > * "Agent/Region Interaction Protocol" (ARIP) - highlights the active > entities > > Are there any other suggestions, preferences, or vetos? Does the proposed > protocol name need to be reflected in a revised Working Group name? > Contrariwise, does the WG name need to be reflected in protocols it > develops? (Strictly: "no" and "no", but in practice...?) Serious name > suggestions which promote clever acronyms for future IETF sessions are > encouraged. > > > 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? > > > 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. > > > 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. > > > 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. > > > 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. > > > 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? > > (This may affect the terminology used for #11.) > > > _______________________________________________ > ogpx mailing list > ogpx@ietf.org > https://www.ietf.org/mailman/listinfo/ogpx > --0016e6dab171527f2304700d300d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jul 30, 2009 at 8:39 AM, Joshua Bell <josh@lindenlab.com> wrote:
=

Necessary charter changes:

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, educa= tional, and catchy?


Joshua, I've been looking at one particular aspect= of how to define our problem space in such a way that it is concise and na= rrow enough to exclude the "interop all worlds" of MMOX, while at= the same time flexible and broad enough to make it apply to more than just= exact Second Life clones.=A0 In other words, how to define the catchment a= rea such that OGP becomes a worthwhile protocol for more than just one comp= any's goals.

One of the best ways of tackling this is to directly ask who it actu= ally applies to.=A0 What kinds of worlds could interoperate through OGP= ?

This question is often answered in an informal way:=A0 "OGP a= llows interoperation between SL-like worlds."=A0 That answer is fair e= nough when given loosely and informally, but it is not good enough for an I= ETF spec, for obvious reasons.=A0 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 be= tween any virtual worlds that implement the protocol."
This almost sounds recursive, but it is not:=A0 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 proto= col.=A0 It no longer mentions Second Life.=A0 It does not refer to a totall= y fictitious unit of "the world".=A0 It does not require interope= rating worlds to be clones, either implicitly or explicitly.=A0 It clearly = states that the ONLY requirement for interop is implementing this one proto= col, or suite.

In other words, it avoids being prescriptive about worlds, and it lets = adherence to the protocol define the universe of interop.

That sound= s to me like a very good basis for a charter upon which to build a protocol= that=A0 satisfies the known goals of OGP as we have discussed for almost t= wo years, while at the same time being in tune with the Mission Statement o= f the IETF in respect of wide deployment and interoperation on the Internet= .

I propose that the current charter be rephrased to make the above plain= , because in its current form it is unnecessarily restrictive and inconsist= ent in its reference to virtual worlds.=A0 I can have a go at this myself i= f you like.


Morgaine.







=A0

On Thu, Jul 30, 2009 at 8:39 AM, Joshua Bell = <josh@lindenlab.com>= wrote:
A draft WG charte= r was discussed at the BOF, the text of which can be found here:

http://www.ietf.org/proceedings/75/slides/ogpx-2.txt

Our highest priority goal is to refine the charter. The BOF provided us wit= h an excellent set of questions and issues to address. These have not yet b= een incorporated, and are listed below along with open questions.

* We are looking for feedback in the form of specific changes to make to th= e proposed charter and rationale for the language used.

* We have an explicit goal of submitting the charter within 2 weeks to the = ISEG and IAB for approval.


Necessary charter changes:


1. Include a succinct but realistic summary of what the problem space and p= rotocol 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 re= ally cool." (thanks, Chris!). This really helped BOF participants unfa= miliar with VWs understand what the heck we were talking about.

Can mailing list participants come up with something short, accurate, educa= tional, and catchy?


2. Larry Masinter and Dave Crocker argued persuasively for a functional des= cription of the protocol's uses. Rather than describe the protocol only= in abstract terms, provide a non-exhaustive list of protocol effects. For = example: "The protocol produced by this working group should provide 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= list of objects in the user's avatar, etc."


3. The text of the charter should have a clear list of working group delive= rables.

The "what is needed" slide from the OGPX Draft Charter Issues pre= sentation ( http://www.ietf.org/proceedings/75/slides/ogpx-2.pdf) was mentioned as a possible source for this list for both (2) and (3), b= ut 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,

Are there any deliverables missing? Have we covered the functional needs. W= hen proposing additional deliverables, please describe them in sufficient d= etail to enable discussion.


4. A small number of key terms should be introduced and briefly described, = especially any used in the functional description (#2, above). Suggestions = for these terms include agent, avatar, user, region, asset, domain, service= , resource, agent domain and region domain.

Ultimately the list of terms to include will be derived from other parts of= the charter to make it independent of other texts, but are there other ter= ms that must be defined?


5. Should the working group investigate operational aspects of virtual worl= ds? If so, what language should be added to the charter?


6. "OGP" is not an appropriate name for the WG or protocol - &quo= t;grid" is ambiguous. (Our usage plays off the double meaning of a squ= are subdivision of regions, and a computing cluster, neither of which are e= xpected to be explicit in the protocol.) Suggestions so far include:

* "Region Access Protocol" (RAP) - captures region-based VW speci= ficity
* "Agent/Region Interaction Protocol" (ARIP) - highlights the act= ive entities

Are there any other suggestions, preferences, or vetos? Does the proposed p= rotocol name need to be reflected in a revised Working Group name? Contrari= wise, does the WG name need to be reflected in protocols it develops? (Stri= ctly: "no" and "no", but in practice...?) Serious name = suggestions which promote clever acronyms for future IETF sessions are enco= uraged.


7. Explicitly list extant drafts which will be the starting point for the W= G 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?


8. The protocols are intended to provide a clear seperation of concerns bet= ween mechanisms =A0used to access resources and policies controlling use of= those mechanisms. Many deployment choices will be defined by policy, not p= rotocol. This needs to be clear in the charter.


9. Ensure that while the charter scopes down the Virtual World problem spac= e, it does it in an inclusive way rather than focusing on what is out of sc= ope and thus indecipherable to non-subject matter experts. It is expected t= hat output of the WG may be useful in scenarios beyond those specifically u= nder consideration, much as RFC 2068 is not simply used for hypertext.


10. Remove references to "wire" in "wire protocol"; thi= s is implicit in the scope of work for IETF. The phrase "application-l= ayer protocol" (as distinct from a novel transport-layer protocol) is = accurate and sufficient.


11. Add text specifying: The WG will define interfaces for a set of HTTP-ba= sed services ("web services") but not provide language specific b= indings ("API") onto those services.


12. Clarify the charter that we're explicitly targetting HTTP as the de= fault transport.

A concern was raised that reusing HTTP will lead to unnecessary and tight c= oupling 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 ta= rget HTTP, or make the effort?

(This may affect the terminology used for #11.)


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

--0016e6dab171527f2304700d300d--