From meadhbh.siobhan@gmail.com Tue May 19 13:13: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 8C40B3A70D3 for ; Tue, 19 May 2009 13:13:13 -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 JVhpxbj4yHrn for ; Tue, 19 May 2009 13:13:12 -0700 (PDT) Received: from mail-gx0-f166.google.com (mail-gx0-f166.google.com [209.85.217.166]) by core3.amsl.com (Postfix) with ESMTP id C6CB23A70CF for ; Tue, 19 May 2009 13:13:09 -0700 (PDT) Received: by gxk10 with SMTP id 10so43852gxk.13 for ; Tue, 19 May 2009 13:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=vBuywiRNcPcQz1CRJtq+Z8h4hkGp8BSHXu5rs+J/I24=; b=IOC9lYwmpkKBrOWfJ+8zikA0I9glNmS0ogePMBOcnPdae1GJggLyioIRbYsIAkQC4V 3k/RqiTApRwmkd0AADvQV3rLYuPaSMlrBZIICBIskvIYlRsvnhkWtSqTT6aJ92CFk2Ig EnC4sfB08P4S7X4rDIwRI7ELw4D4eVRasTmDI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=oubabW0wuWMQNiWAMLG0mYIN0xW4LGWtYME/fcw0S1iW/lGMszy3ZXSluIWRuuXXU/ NGK2Ak8W9hrjCb6qpVPK+00I01Z+F0RNfKHfZBlQGC4DKZujwGES1XvXlWHwpILuor7l 2Tv2zNis2hubPZbSglkrQuMkNIA9Jol8T9TJA= MIME-Version: 1.0 Received: by 10.100.248.4 with SMTP id v4mr913027anh.57.1242764084656; Tue, 19 May 2009 13:14:44 -0700 (PDT) Date: Tue, 19 May 2009 13:14:44 -0700 Message-ID: From: Meadhbh Siobhan To: ogpx@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [ogpx] testing... one two three 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, 19 May 2009 20:18:57 -0000 hmm... hey... is this thing working? From meadhbh.siobhan@gmail.com Tue May 19 13:19:19 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C03153A70E2 for ; Tue, 19 May 2009 13:19:19 -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 pgoadZw3QAoY for ; Tue, 19 May 2009 13:19:19 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by core3.amsl.com (Postfix) with ESMTP id 09D1D28C24B for ; Tue, 19 May 2009 13:19:08 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so26796yxb.49 for ; Tue, 19 May 2009 13:20:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=o8QG4ME+wGJGrCUyzkTpnUCwmMKlsBagsM9lSUg2wbU=; b=Ex6GRxDUh7o/PD+z0qL58vW9rMFOe45RZkve4a3YHPJLDxBj7In0FA1fHOUk+g/Fpa nK0tmGL7xkriof8QTj4p1S4+zW5v1OctNGte0YXoO/n+W7LD617jysmfRtsMlYW/28eO Ky+cfni3IoUD0ktkkyO+ndGOqqb6Dsi37s2AA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=R8zXria3XHO1FMElr4yRlGeDNRJNQfwmdIBAhSpgE6R5VwZH657iiReIVzAvEXdQAC oYt6h/TySoYVMaa+zdRvdbhQ0TQDVpOnN+aed0kgd7K0H82UlH97IwmETYO6Dn7GtNog psRg4/CmGNTQyQpT+ThAtQCAzGBZPTaKO2HEM= MIME-Version: 1.0 Received: by 10.100.138.10 with SMTP id l10mr900265and.61.1242764432497; Tue, 19 May 2009 13:20:32 -0700 (PDT) Date: Tue, 19 May 2009 13:20:32 -0700 Message-ID: From: Meadhbh Siobhan To: ogpx@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [ogpx] testing again .. two three ... five 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, 19 May 2009 20:19:19 -0000 testing... testing... From john.hurliman@intel.com Tue May 19 13:23: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 4FE223A70C4 for ; Tue, 19 May 2009 13:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.439 X-Spam-Level: X-Spam-Status: No, score=-6.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, 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 4V4wYjgZ27qG for ; Tue, 19 May 2009 13:23:17 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by core3.amsl.com (Postfix) with ESMTP id 987C73A6E67 for ; Tue, 19 May 2009 13:23:17 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 19 May 2009 13:15:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.41,217,1241420400"; d="scan'208";a="413910926" Received: from rrsmsx602.amr.corp.intel.com ([10.31.0.33]) by orsmga002.jf.intel.com with ESMTP; 19 May 2009 13:32:16 -0700 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx602.amr.corp.intel.com ([10.31.0.33]) with mapi; Tue, 19 May 2009 14:24:36 -0600 From: "Hurliman, John" To: Meadhbh Siobhan , "ogpx@ietf.org" Date: Tue, 19 May 2009 14:24:34 -0600 Thread-Topic: [ogpx] testing again .. two three ... five Thread-Index: AcnYv1Kpp6wT1SNMQHu8psJOJCWVOwAAHkVA Message-ID: <62BFE5680C037E4DA0B0A08946C0933D90A48C16@rrsmsx506.amr.corp.intel.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ogpx] testing again .. two three ... five 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, 19 May 2009 20:23:18 -0000 pong >-----Original Message----- >From: ogpx-bounces@ietf.org [mailto:ogpx-bounces@ietf.org] On Behalf Of >Meadhbh Siobhan >Sent: Tuesday, May 19, 2009 1:21 PM >To: ogpx@ietf.org >Subject: [ogpx] testing again .. two three ... five > >testing... testing... >_______________________________________________ >ogpx mailing list >ogpx@ietf.org >https://www.ietf.org/mailman/listinfo/ogpx >=20 From missannotoole@yahoo.com Tue May 19 13:38: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 017023A7093 for ; Tue, 19 May 2009 13:38:54 -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 RhUc9TjhN3Zc for ; Tue, 19 May 2009 13:38:53 -0700 (PDT) Received: from web59104.mail.re1.yahoo.com (web59104.mail.re1.yahoo.com [66.196.101.15]) by core3.amsl.com (Postfix) with SMTP id 187203A6F12 for ; Tue, 19 May 2009 13:38:53 -0700 (PDT) Received: (qmail 77597 invoked by uid 60001); 19 May 2009 20:39:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1242765585; bh=y0rfXWw1csI8nr0lId6rDj8S51Re89a5P/O0krfPTWQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=lfndKg4TvrQBQbyECUhgYz7qp2cRXKHHYI2vpELEnkXN8gLnnDThjabVb1WmvLqRr/sgFS577gY930v+M69ZbK/7051VxxIIgBNmih4nyfMa2WmxIeWidzdoIbRyrY9emExkTbmO3YM0CwEgCaIdamcZJakP/pUM2jNq04AqT4w= 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=5/rfvwUmBqePWGdJhmpmHuAfcwirM7X7BBZUkVPUIYOMt7t67YHmceEivn2pD8Y7YG+6mjDb5QM4XXvqeuzOcespFMhfOJsUfXxm0ooFxWFzXv//tzHg56ZldyxNof1CrHTHGbu5cRKvORVr34MkJzNKdFQIlFpmssyyVP1EoOc=; Message-ID: <714947.77590.qm@web59104.mail.re1.yahoo.com> X-YMail-OSG: hD.KZLAVM1l3oNqn7Ta9qFo8V4PyHMwg1idcQOOFlb0SznVFrgXUh.bhMHKT.SC.jzSBXCYGdUH6lniMXZNhIuQmvNmB3IoWUyMWiQyMYbVJtAhROtG_uNvCqwEkluj2SGibpTGStIFl5AuoNFtwKSQYewVBRV14KDxwuSDTk.0d7V6uy6.cDpRhvDTgcibpeEKeIudOmLxFfbYRjOQHifuiPEHjIBXSV2J10w7GkDYoWUCMIu1NlLo8WE6brhrkBkXanoflo_dKwWoEPNsH58wCengqiMcQoIHBS.EHn9M4QIAuAZNz.0luoSCxdXOtV6RQ1TtOZ0PQ6IU- Received: from [173.170.98.145] by web59104.mail.re1.yahoo.com via HTTP; Tue, 19 May 2009 13:39:45 PDT X-Mailer: YahooMailRC/1277.43 YahooMailWebService/0.7.289.10 References: Date: Tue, 19 May 2009 13:39:45 -0700 (PDT) From: Ann Otoole To: Meadhbh Siobhan , ogpx@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1012983770-1242765585=:77590" Subject: Re: [ogpx] testing again .. two three ... five 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, 19 May 2009 20:38:54 -0000 --0-1012983770-1242765585=:77590 Content-Type: text/plain; charset=us-ascii working. proceed with future. ________________________________ From: Meadhbh Siobhan To: ogpx@ietf.org Sent: Tuesday, May 19, 2009 4:20:32 PM Subject: [ogpx] testing again .. two three ... five testing... testing... _______________________________________________ ogpx mailing list ogpx@ietf.org https://www.ietf.org/mailman/listinfo/ogpx --0-1012983770-1242765585=:77590 Content-Type: text/html; charset=us-ascii
working.

proceed with future.

From: Meadhbh Siobhan <meadhbh.siobhan@gmail.com>
To: ogpx@ietf.org
Sent: Tuesday, May 19, 2009 4:20:32 PM
Subject: [ogpx] testing again .. two three ... five

testing... testing...
_______________________________________________
ogpx mailing list
ogpx@ietf.org
https://www.ietf.org/mailman/listinfo/ogpx

--0-1012983770-1242765585=:77590-- From infinity@lindenlab.com Tue May 19 15:03:17 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CBB43A713C for ; Tue, 19 May 2009 15:03:17 -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.301, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=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 3vOzEoH3SpX1 for ; Tue, 19 May 2009 15:03:16 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.31]) by core3.amsl.com (Postfix) with ESMTP id 02B6E28C387 for ; Tue, 19 May 2009 15:01:55 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so83880ywj.49 for ; Tue, 19 May 2009 15:03:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.108.2 with SMTP id g2mr1137564anc.35.1242770610845; Tue, 19 May 2009 15:03:30 -0700 (PDT) In-Reply-To: <3a880e2c0905191413o7d9eb8f4x1fedd755601df8d0@mail.gmail.com> References: <3a880e2c0905191405u6355b6aatd096fece425a4beb@mail.gmail.com> <3a880e2c0905191413o7d9eb8f4x1fedd755601df8d0@mail.gmail.com> Date: Tue, 19 May 2009 15:03:30 -0700 Message-ID: <3a880e2c0905191503m1d2d0f63q43bf28c6f3b2c39d@mail.gmail.com> From: Infinity Linden To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=0016e64402a0cbfeeb046a4b14e6 Subject: [ogpx] Fwd: welcome to the ogpx list 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, 19 May 2009 22:03:17 -0000 --0016e64402a0cbfeeb046a4b14e6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Welcome to the OGPX mailing list! I just wanted to send out a brief note welcoming people to the OGPX mailing list. The purpose of this list is currently twofold: discuss the Open Grid Protocol (OGP) family of protocols and discuss the draft charter for the OGPX working group. To recap why this list was formed... In February of 2009, the MMOX list was formed to contain discussions about virtual worlds protocols, culminating in a Birds of a Feather (BoF) meeting at the 74th IETF meeting in San Francisco. The scope of the MMOX effort was intentionally broad as it's participants attempted to identify core aspects of a general virtual worlds protocol; and this effort continues on the MMOX list. A critique was offered by some MMOX BoF attendees that the broad scope made it difficult to understand what was being standardized. It became apparent that there may be advantages to establishing a second group, a group focused exclusively on the OGP protocol suite. OGP is currently "officially" described in a series of internet drafts: http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 (OGP: Introduction and Requirements) The "Introduction and Requirements" draft is an attempt to broadly define the problem domain of interoperable virtual worlds and introduce architectural patterns in its solution. http://tools.ietf.org/html/draft-hamrick-llsd-00, Draft 00 (LLSD) LLSD describes an abstract type system and a protocol interaction interface description language. OGP services are defined using LLSD. http://tools.ietf.org/html/draft-lentczner-ogp-base-00 (OGP: Base) This document describes fundamental aspects of OGP including Capabilities and Event Queues. http://tools.ietf.org/html/draft-hamrick-ogp-auth (OGP: Authentication) This document describes techniques for user authentication, the first step when interacting with an OGP service. readers may also be interested in the reverse http draft as it may have bearing on the implementation of OGP:Base EventQueues: http://tools.ietf.org/html/draft-lentczner-rhttp-00 (Reverse HTTP) Reverse HTTP describes a mechanism for introducing bidirectional http. In other words, it describes the protocol that allows a client to connect to a RHTTP compliant server to establish a connection, then allows the server to send a request to the client. As a convenience, I am maintaining a wiki page at http://wiki.secondlife.com/wiki/User:Infinity_Linden/IETF_Drafts_and_Meetings which SHOULD point to the most recent OGP drafts. The proposed working group charter will be sent to this list again soon so charter bashing can occur in a different thread. (there might have been a technical glitch preventing it's earlier appearance on the ogpx list) Over the next several months, we hope to see new revisions of the drafts listed above and discussion about the drafts. With the creation of the OGPX list, discussion specific to these drafts SHOULD occur here in preference to the MMOX list. Discussion of MMO protocol in general SHOULD occur in MMOX in preference to OGPX. Sincerely Meadhbh Hamrick --0016e64402a0cbfeeb046a4b14e6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Welcome to the OGPX mailing list!

I just wanted to send out a brief note welcoming people to the OGPX
mailing list. The purpose of this list is currently twofold: discuss
the Open Grid Protocol (OGP) family of protocols and discuss the draft
charter for the OGPX working group.

To recap why this list was formed... In February of 2009, the MMOX
list was formed to contain discussions about virtual worlds protocols,
culminating in a Birds of a Feather (BoF) meeting at the 74th IETF
meeting in San Francisco. The scope of the MMOX effort was
intentionally broad as it's participants attempted to identify core
aspects of a general virtual worlds protocol; and this effort
continues on the MMOX list. A critique was offered by some MMOX BoF
attendees that the broad scope made it difficult to understand what
was being standardized. It became apparent that there may be
advantages to establishing a second group, a group focused exclusively
on the OGP protocol suite.

OGP is currently "officially" described in a series of internet drafts:

http://tools.ietf.org/html/draft-hamrick-ogp-intro-00 (OGP:
Introduction and Requirements)
The "Introduction and Requirements" draft is an attempt to broadly
define the problem domain of interoperable virtual worlds and
introduce architectural patterns in its solution.

http://tools.ietf.org/html/draft-hamrick-llsd-00, Draft 00 (LLSD)
LLSD describes an abstract type system and a protocol interaction
interface description language. OGP services are defined using LLSD.

http://tools.ietf.org/html/draft-lentczner-ogp-base-00 (OGP: Base)
This document describes fundamental aspects of OGP including
Capabilities and Event Queues.

http://tools.ietf.org/html/draft-hamrick-ogp-auth (OGP: Authentication)
This document describes techniques for user authentication, the first
step when interacting with an OGP service.

readers may also be interested in the reverse http draft as it may
have bearing on the implementation of OGP:Base EventQueues:

http://tools.ietf.org/html/draft-lentczner-rhttp-00 (Reverse HTTP)
Reverse HTTP describes a mechanism for introducing bidirectional http.
In other words, it describes the protocol that allows a client to
connect to a RHTTP compliant server to establish a connection, then
allows the server to send a request to the client.

As a convenience, I am maintaining a wiki page at
http://wiki.secondlife.com/wiki/User:Infinity_Linden/IETF_Drafts_and_Meetings
which SHOULD point to the most recent OGP drafts.

The proposed working group charter will be sent to this list again
soon so charter bashing can occur in a different thread. (there might
have been a technical glitch preventing it's earlier appearance on the
ogpx list)

Over the next several months, we hope to see new revisions of the
drafts listed above and discussion about the drafts. With the creation
of the OGPX list, discussion specific to these drafts SHOULD occur
here in preference to the MMOX list. Discussion of MMO protocol in
general SHOULD occur in MMOX in preference to OGPX.

Sincerely
Meadhbh Hamrick


--0016e64402a0cbfeeb046a4b14e6-- From infinity@lindenlab.com Tue May 19 15:03:24 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 784B23A68D2 for ; Tue, 19 May 2009 15:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.826 X-Spam-Level: X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=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 9jLyLHWH4VZp for ; Tue, 19 May 2009 15:03:20 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by core3.amsl.com (Postfix) with ESMTP id 7616A3A6EB5 for ; Tue, 19 May 2009 15:02:34 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so84297ywj.49 for ; Tue, 19 May 2009 15:04:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.216.10 with SMTP id o10mr994736ang.159.1242770648709; Tue, 19 May 2009 15:04:08 -0700 (PDT) In-Reply-To: <3a880e2c0905191407j25bf2544xea022e4967228bc1@mail.gmail.com> References: <3a880e2c0905191407j25bf2544xea022e4967228bc1@mail.gmail.com> Date: Tue, 19 May 2009 15:04:08 -0700 Message-ID: <3a880e2c0905191504w2e98672cx620827a6d606c685@mail.gmail.com> From: Infinity Linden To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=0016368e24ce0dbc94046a4b1712 Subject: [ogpx] Fwd: OGPX Draft 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: Tue, 19 May 2009 22:03:24 -0000 --0016368e24ce0dbc94046a4b1712 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Working Group Name: Open Grid Protocol (OGPX) Chairs: TBD Area and Area Directors: Applications Area Lisa Dusseault Alexey Melnikov Responsible Area Director: TBD Mailing List:ogpx@ietf.org ( subscribe at https://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 a) enable interoperability between applications, b) provide for access and exchange with other systems on the internet such as web services, e-mail and other information storage systems, c) allow network layers to recognize VW traffic and make routing decisions based on its characteristics. The Open Grid Protocol (OGP) describes semantics and protocol interaction for the virtual world, independent of transport, though bindings for carrying OGP over HTTP are 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 defines 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 Foundational components of the Open Grid Protocol include the publication of: 1) the LLSD dynamic structured data system; an abstract type system for representing application layer objects along with serialization rules for protocol messages between these objects. 2) OGP Base, a messaging abstraction to support the unique needs of VW interactions. 3) Guidelines for using OAuth and PKIX compliant X.509 infrastructure to authenticate protocol endpoints. The Open Grid Protocol makes use, wherever possible, of existing, established standards. The OGPX working group is not proposing the standardization of any one complete proprietary protocol, but to build on existing OGP related internet drafts: 1. LLSD Dynamic Structure Data 2. Open Grid Protocol : Base 3. Open Grid Protocol : Authentication An additional deliverable describes the use of how OAuth or PKIX compliant digital certificates may be used with TLS to provide origin integrity in inter-host protocol interactions. Another deliverable is the specification for presence establishment in the virtual world based on the previous "OGP : Teleport" draft of the second life architecture working group. Goals and Milestones: - *October 2009* Publication of the PKIX Profile for Inter-Simulator Communication Draft as an Informational RFC - *October 2009* Publication of the OGP: Requirements and Introduction as an Informational RFC - *February 2010* Progression of LLSD to Proposed Standard - *February 2010* Progression of OGP Base to Proposed Standard - *February 2010* Progression of OGP Virtual World Primitive Object Format to Proposed Standard - *June 2010* Progression of OGP Authentication to Proposed Standard - *June 2010* Progression of OGP Presence Establishment to Proposed Standard --0016368e24ce0dbc94046a4b1712 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Working Group Name:

Open Grid Protocol (OGPX)

Chairs:

TBD

Area and Area Directors:

Applications Area

Lisa Dusseault <lisa.dusseault@messagingarchitects.com>

Al= exey Melnikov <alexey.melnikov@isode.com>

Responsible Area Director:

TBD

Mailing List:

Description of Working Group:

Virtual Worlds (VWs) and other Mas= sively Multi-Party Online Applications (MMOs) are of increasing interest to= the Internet community. Innumerable examples exist of such applications, m= ost using proprietary protocols. With their roots in games and social inter= action, Virtual Worlds are now being used increasingly in business, educati= on and information exchange. With a growing user base, creators of such sys= tems are interested in developing a standard virtual worlds protocol to ena= ble interoperability.

The objective of the OGPX working group is to provide an application-lay= er wire protocol for Virtual Worlds to a) enable interoperability between a= pplications, b) provide for access and exchange with other systems on the i= nternet such as web services, e-mail and other information storage systems,= c) allow network layers to recognize VW traffic and make routing decisions= based on its characteristics. The Open Grid Protocol (OGP) describes seman= tics and protocol interaction for the virtual world, independent of transpo= rt, though bindings for carrying OGP over HTTP are defined.

The core work of the group will be the production of the Open Grid Proto= col suite (OGP), a set of application protocols to communicate and interact= with the state of Virtual World applications. The Open Grid Protocol defin= es 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
  • th= e virtual world contains persistent objects
  • the virtual world may b= e partitioned
  • presence, state and simulation occur on authoritative hosts
Foundational components of the Open Grid Protocol include the publication = of: 1) the LLSD dynamic structured data system; an abstract type system for= representing application layer objects along with serialization rules for = protocol messages between these objects. 2) OGP Base, a messaging abstracti= on to support the unique needs of VW interactions. 3) Guidelines for using = OAuth and PKIX compliant X.509 infrastructure to authenticate protocol endp= oints. The Open Grid Protocol makes use, wherever possible, of existing, es= tablished standards.

The OGPX working group is not proposing the standardization of any one c= omplete proprietary protocol, but to build on existing OGP related internet= drafts:

  1. LLSD Dynamic Structure Data
  2. Open Grid Protocol = : Base
  3. Open Grid Protocol : Authentication

An additional deliverab= le describes the use of how OAuth or PKIX compliant digital certificates ma= y be used with TLS to provide origin integrity in inter-host protocol inter= actions. Another deliverable is the specification for presence establishmen= t in the virtual world based on the previous "OGP : Teleport" dra= ft of the second life architecture working group.

Goals and Milestones:

  • October 2009=A0Publi= cation of the PKIX Profile for Inter-Simulator Communication Draft as an In= formational RFC
  • October 2009=A0Publication of the = OGP: Requirements and Introduction as an Informational RFC
  • February 2010=A0Progression of LLSD to Proposed Standa= rd
  • February 2010=A0Progression of OGP Base to Prop= osed Standard
  • February 2010=A0Progression of OGP V= irtual World Primitive Object Format to Proposed Standard
  • June 2010=A0Progression of OGP Authentication to Propo= sed Standard
  • June 2010=A0Progression of OGP Presen= ce Establishment to Proposed Standard

--0016368e24ce0dbc94046a4b1712-- From infinity@lindenlab.com Tue May 19 15: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 202703A6A1F for ; Tue, 19 May 2009 15:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.947 X-Spam-Level: X-Spam-Status: No, score=-0.947 tagged_above=-999 required=5 tests=[AWL=-0.830, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4u51w5DmfqyF for ; Tue, 19 May 2009 15:34:28 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by core3.amsl.com (Postfix) with ESMTP id 595703A6EC4 for ; Tue, 19 May 2009 15:34:28 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so101066ywj.49 for ; Tue, 19 May 2009 15:36:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.207.17 with SMTP id e17mr1006532ang.137.1242772563310; Tue, 19 May 2009 15:36:03 -0700 (PDT) Date: Tue, 19 May 2009 15:36:03 -0700 Message-ID: <3a880e2c0905191536l4c616a94v5d681f675770831c@mail.gmail.com> From: Infinity Linden To: ogpx@ietf.org Content-Type: multipart/alternative; boundary=001636b149732c52d7046a4b8962 Subject: [ogpx] Special Thanks to Steve and the team at amsl.com 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, 19 May 2009 22:34:29 -0000 --001636b149732c52d7046a4b8962 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I just want to say a special thank you to Steve Young and the rest of the team at amsl.com who are responsible for making the IETF mailing lists work. -Thanks Steve (and everyone else!) -Meadhbh --001636b149732c52d7046a4b8962 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I just want to say a special thank you to Steve Young and the rest of the team at amsl.com who are responsible for making the IETF mailing lists work.

-Thanks Steve (and everyone else!)
-Meadhbh
--001636b149732c52d7046a4b8962-- From infinity@lindenlab.com Fri May 29 13:57: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 A26B43A6960 for ; Fri, 29 May 2009 13:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.714 X-Spam-Level: X-Spam-Status: No, score=-0.714 tagged_above=-999 required=5 tests=[AWL=-0.596, 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 qPHrvqaRSnw4 for ; Fri, 29 May 2009 13:57:03 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id EB06A3A6B00 for ; Fri, 29 May 2009 13:57:02 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so6148661yxb.49 for ; Fri, 29 May 2009 13:58:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.251.8 with SMTP id y8mr4513890anh.74.1243630725199; Fri, 29 May 2009 13:58:45 -0700 (PDT) Date: Fri, 29 May 2009 13:58:45 -0700 Message-ID: <3a880e2c0905291358j3c924eb0i9791e9836d54b15d@mail.gmail.com> From: Infinity Linden To: ogpx@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [ogpx] draft charter comments 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, 29 May 2009 20:57:03 -0000 hey peeps! i heard a few comments regarding the OGPX draft charter last week in other forums... can we bring them up again here to get the discussion going again? -cheers -meadhbh From infinity@lindenlab.com Fri May 29 13:57: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 8F3533A6FDB for ; Fri, 29 May 2009 13:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.544 X-Spam-Level: X-Spam-Status: No, score=-1.544 tagged_above=-999 required=5 tests=[AWL=0.433, 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 XnhfMSg8uKoB for ; Fri, 29 May 2009 13:57:38 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id 856E53A6F46 for ; Fri, 29 May 2009 13:57:38 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so6148951yxb.49 for ; Fri, 29 May 2009 13:59:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.120.10 with SMTP id s10mr4368456anc.86.1243630760555; Fri, 29 May 2009 13:59:20 -0700 (PDT) In-Reply-To: <3a880e2c0905291356w64a89d1an640ed68196225911@mail.gmail.com> References: <3a880e2c0905291356w64a89d1an640ed68196225911@mail.gmail.com> Date: Fri, 29 May 2009 13:59:20 -0700 Message-ID: <3a880e2c0905291359r6383f485u12ba2235a963b46d@mail.gmail.com> From: Infinity Linden To: ogpx@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [ogpx] issue : naming of capabilities in OGP 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, 29 May 2009 20:57:39 -0000 hey peeps... just thought i would try to kick off a couple technical discussions... so... if you look at the auth spec ( http://tools.ietf.org/html/draft-hamrick-ogp-auth-00 ), you'll note that the client application is supposed to tell the agent domain what capabilities (caps) it wants. this assumes the client application knows the cap names and how to interact with the system hosting the cap. (we _could_ get into a discussion about service discovery here, but i'm hoping to limit the discussion on this thread to just the naming issue.) currently, capability names are descriptive strings (like "place/avatar" and so forth.) There is a recommendation that we use URIs of the following format as cap names: "standard" capabilities defined by OGP should be identified as a URN in the format: =A0 URN:OGP: ("urn:ogp:/avatar/place" or "urn:ogp:/eventqueue/get") private extensions might be identified by URNs like: =A0URN:OGP:/ ("urn:ogp:org.opensimulator/chatsession/create" or even "urn:ogp:org.example/avatar/place") so... to define it a little more formally with EBNF, you could say that the OGP URN looks like: ogpurn =3D 'URN:OGP:' , [ authority ] =A0, capname ; capname =3D { fragment } ; fragment =3D '/' =A0, { alphanumeric } ; alphanumeric =3D alpha | digit ; alphabetic character =3D "A" | "B" | "C" | "D" | "E" | "F" | "G" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | "H" | "I" | "J" | "K" | "L" | "M"= | "N" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | "O" | "P" | "Q" | "R" | "S" | "T"= | "U" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | "V" | "W" | "X" | "Y" | "Z" | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "a" | "b" | "c" | "d" | "e" | "= f" | "g" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | "h" | "i" | "j" | "k" | "l" | "m"= | "n" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | "o" | "p" | "q" | "r" | "s" | "t"= | "u" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | "v" | "w" | "x" | "y" | "z" ; digit =3D "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" ; (also... insert the appropriate EBNF description of a fqdn for authority (i'm too lazy to copy it.) and if you wanted to get wild and conflate the name of the cap with the location of a resource about the cap, you would use a traditonal RFC2616 / 2817 http / https url like ("http://example.org/capabilities/avatar/place") the development for this recommendation is... * i made the recommendation that since peeps might want to create extensions to OGP (in fact, OGP is expected to have extensions if for no other reason than we can test capabilities before they're codified in an rfc.) i was exposed to the java way of naming classes which is to start the name of your class as the reverse of each element in your organization's FQDN. So.. I recommended something like "com.lindenlab.extension.foo" for linden-specific extensions "com.ibm.extension.bar" for IBM specific extensions, etc. * this left open the question of how do we denote standard cap names that are defined in the spec. putting them under "com.lindenlab" is inappropriate because OGP is a community effort. and doing the java thing of putting standard caps under "ogp." is probably bad 'cause ICANN is going to start allowing peeps to register arbitrary TLDs any day now; creating a spec that requires SOMEONE to partner with a registry so we can control the ogp.* namespace to prevent name collisions is a plan fraught with peril. * plus... John has an interest in using URLs as opaque cap identifiers. and the solution that came out of it was using a URN. this would require us to approach IANA and get a URN NID for OGP which is a non-zero amount of work. also... the way i've defined it, we're limiting cap names to ASCII characters which may be inappropriate in an international world. -comments? -questions? -cheers! -meadhbh From masinter@adobe.com Sun May 31 12:39: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 B01FB3A6C83 for ; Sun, 31 May 2009 12:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[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 ggtg36oDsVS6 for ; Sun, 31 May 2009 12:39:02 -0700 (PDT) Received: from exprod6og107.obsmtp.com (exprod6og107.obsmtp.com [64.18.1.208]) by core3.amsl.com (Postfix) with ESMTP id D4FA63A6E08 for ; Sun, 31 May 2009 12:38:56 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob107.postini.com ([64.18.5.12]) with SMTP ID DSNKSiLc0Pr+8XKrRdRGppl2CLSqFxCNDdKW@postini.com; Sun, 31 May 2009 12:39:00 PDT Received: from inner-relay-3.eur.adobe.com ([192.150.8.236]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n4VJWpao014422; Sun, 31 May 2009 12:32:52 -0700 (PDT) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id n4VJcqY2012772; Sun, 31 May 2009 12:38:52 -0700 (PDT) Received: from fe01.corp.adobe.com (10.8.192.82) by nacas01.corp.adobe.com (10.8.189.99) with Microsoft SMTP Server (TLS) id 8.1.340.0; Sun, 31 May 2009 12:38:51 -0700 Received: from nambx04.corp.adobe.com ([10.8.127.98]) by fe01.corp.adobe.com ([10.8.192.82]) with mapi; Sun, 31 May 2009 12:38:51 -0700 From: Larry Masinter To: Infinity Linden , "ogpx@ietf.org" Date: Sun, 31 May 2009 12:38:48 -0700 Thread-Topic: [ogpx] issue : naming of capabilities in OGP Thread-Index: AcngoFs42/wzHZ+8Q3qoTzKbYRURYwBhi7zQ Message-ID: <8B62A039C620904E92F1233570534C9B0118CD95EC85@nambx04.corp.adobe.com> References: <3a880e2c0905291356w64a89d1an640ed68196225911@mail.gmail.com> <3a880e2c0905291359r6383f485u12ba2235a963b46d@mail.gmail.com> In-Reply-To: <3a880e2c0905291359r6383f485u12ba2235a963b46d@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ogpx] issue : naming of capabilities in OGP 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, 31 May 2009 19:39:03 -0000 > and if you wanted to get wild and conflate the name of the cap with > the location of a resource about the cap, you would use a traditonal > RFC2616 / 2817 http / https url like > ("http://example.org/capabilities/avatar/place") Personally I'm pretty neutral, but I know lots of people who would claim that using the URI of a resource about the capability as the name of the capability as an important element of=20 web architecture, i.e., that it isn't "wild" but it is expected. The main thing that isn't clear is what the namespace denotes, though, and why any of the other existing capability namespaces aren't adequate. If the capabilities are about "world location", for example, or "presence information" about someone/someone's avatar's "location", why the namespace of geographic locations aren't used instead, etc. etc. Larry -- http://larry.masinter.net -----Original Message----- From: ogpx-bounces@ietf.org [mailto:ogpx-bounces@ietf.org] On Behalf Of Inf= inity Linden Sent: Friday, May 29, 2009 1:59 PM To: ogpx@ietf.org Subject: [ogpx] issue : naming of capabilities in OGP hey peeps... just thought i would try to kick off a couple technical discussions... so... if you look at the auth spec ( http://tools.ietf.org/html/draft-hamrick-ogp-auth-00 ), you'll note that the client application is supposed to tell the agent domain what capabilities (caps) it wants. this assumes the client application knows the cap names and how to interact with the system hosting the cap. (we _could_ get into a discussion about service discovery here, but i'm hoping to limit the discussion on this thread to just the naming issue.) currently, capability names are descriptive strings (like "place/avatar" and so forth.) There is a recommendation that we use URIs of the following format as cap names: "standard" capabilities defined by OGP should be identified as a URN in the format: =A0 URN:OGP: ("urn:ogp:/avatar/place" or "urn:ogp:/eventqueue/get") private extensions might be identified by URNs like: =A0URN:OGP:/ ("urn:ogp:org.opensimulator/chatsession/create" or even "urn:ogp:org.example/avatar/place") so... to define it a little more formally with EBNF, you could say that the OGP URN looks like: ogpurn =3D 'URN:OGP:' , [ authority ] =A0, capname ; capname =3D { fragment } ; fragment =3D '/' =A0, { alphanumeric } ; alphanumeric =3D alpha | digit ; alphabetic character =3D "A" | "B" | "C" | "D" | "E" | "F" | "G" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | "H" | "I" | "J" | "K" | "L" | "M"= | "N" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | "O" | "P" | "Q" | "R" | "S" | "T"= | "U" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | "V" | "W" | "X" | "Y" | "Z" | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "a" | "b" | "c" | "d" | "e" | "= f" | "g" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | "h" | "i" | "j" | "k" | "l" | "m"= | "n" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | "o" | "p" | "q" | "r" | "s" | "t"= | "u" =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | "v" | "w" | "x" | "y" | "z" ; digit =3D "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" ; (also... insert the appropriate EBNF description of a fqdn for authority (i'm too lazy to copy it.) and if you wanted to get wild and conflate the name of the cap with the location of a resource about the cap, you would use a traditonal RFC2616 / 2817 http / https url like ("http://example.org/capabilities/avatar/place") the development for this recommendation is... * i made the recommendation that since peeps might want to create extensions to OGP (in fact, OGP is expected to have extensions if for no other reason than we can test capabilities before they're codified in an rfc.) i was exposed to the java way of naming classes which is to start the name of your class as the reverse of each element in your organization's FQDN. So.. I recommended something like "com.lindenlab.extension.foo" for linden-specific extensions "com.ibm.extension.bar" for IBM specific extensions, etc. * this left open the question of how do we denote standard cap names that are defined in the spec. putting them under "com.lindenlab" is inappropriate because OGP is a community effort. and doing the java thing of putting standard caps under "ogp." is probably bad 'cause ICANN is going to start allowing peeps to register arbitrary TLDs any day now; creating a spec that requires SOMEONE to partner with a registry so we can control the ogp.* namespace to prevent name collisions is a plan fraught with peril. * plus... John has an interest in using URLs as opaque cap identifiers. and the solution that came out of it was using a URN. this would require us to approach IANA and get a URN NID for OGP which is a non-zero amount of work. also... the way i've defined it, we're limiting cap names to ASCII characters which may be inappropriate in an international world. -comments? -questions? -cheers! -meadhbh _______________________________________________ ogpx mailing list ogpx@ietf.org https://www.ietf.org/mailman/listinfo/ogpx From infinity@lindenlab.com Sun May 31 22:03:15 2009 Return-Path: X-Original-To: ogpx@core3.amsl.com Delivered-To: ogpx@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4EAC3A6C44 for ; Sun, 31 May 2009 22:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.478 X-Spam-Level: X-Spam-Status: No, score=0.478 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455] 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 2te1EnJtpFh9 for ; Sun, 31 May 2009 22:03:15 -0700 (PDT) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by core3.amsl.com (Postfix) with ESMTP id CA0A23A69C4 for ; Sun, 31 May 2009 22:03:14 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so7387319yxb.49 for ; Sun, 31 May 2009 22:03:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.47.10 with SMTP id u10mr6606199anu.17.1243832592178; Sun, 31 May 2009 22:03:12 -0700 (PDT) In-Reply-To: <8B62A039C620904E92F1233570534C9B0118CD95EC85@nambx04.corp.adobe.com> References: <3a880e2c0905291356w64a89d1an640ed68196225911@mail.gmail.com> <3a880e2c0905291359r6383f485u12ba2235a963b46d@mail.gmail.com> <8B62A039C620904E92F1233570534C9B0118CD95EC85@nambx04.corp.adobe.com> Date: Sun, 31 May 2009 22:03:12 -0700 Message-ID: <3a880e2c0905312203u211d702bp1c685b41dfc04311@mail.gmail.com> From: Infinity Linden To: Larry Masinter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "ogpx@ietf.org" Subject: Re: [ogpx] issue : naming of capabilities in OGP 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, 01 Jun 2009 05:03:16 -0000 On Sun, May 31, 2009 at 12:38 PM, Larry Masinter wrote: > > The main thing that isn't clear is what the namespace denotes, > though, and why any of the other existing capability namespaces > aren't adequate. the existing namespace is a collection of names that sort of "evolved" during the OGP beta last year. things like "place/avatar" and "remove/avatar." so the idea of having the URN is that it lets the community define standard capability names while letting individual deployers define new services or new revisions of existing services. for example, let's say we defined a named capability that was used by the client to signal the agent domain to begin the process of rezzing an avatar somewhere. we might want to call it "urn:ogp:/agent/avatar/place". this would be distinct from the capability the agent domain requests from the region domain to place the avatar, which might be called "urn:ogp:/region/avatar/place". Someone at example.com might have an idea for how to improve this process, and might define a named capability called "urn:ogp:example.com/region/avatar/place". For the system to function properly, we just need to make sure distinct capability names are... well... distinct. this format (should) make it much more clear what's going on when people are debugging the protocol stream. like someone might look at the stream as part of debugging and go... "oh! now i understand why this isn't working, it's cause we're asking the region for the _regular_ avatar/place cap, not the example.com avatar/place cap!!!" it also allows two organizations: we'll call them example.net and example.com to both create their own named capabilities for their own experiments or custom protocols. and again... the purpose of the distinct capability names is so the client may ask for distinct capabilities that support distinct interaction semantics. if a server provides both a standard capability AND a custom capability, it's signaling the client that it supports both protocol flows. > If the capabilities are about "world location", for example, > or "presence information" about someone/someone's avatar's > "location", why the namespace of geographic locations aren't > used instead, etc. etc. named capabilities denote a function, not a location. so you might have something like "urn:ogp:/location/find" to request a capability from a region domain that allows a client application to search for a location "in world." So the caps namespace isn't the same as the namespace of public protocol endpoints, but rather a simple identifier. In OGP, you request named capabilities after authentication / authorization. So if you wanted to have each location in the virtual world be addressable as a named capability, you would end up having to relog every time you wanted to find information about a new location. hmm.. rereading the section of the auth spec or the intro/requirements doc, it's not especially clear how named capabilities are to be used. lemme try to post some more about that on the list this week. maybe we could refine the discussion and find an succinct answer to the question "what kind of services are requested with named capabilities?" -cheers -meadhbh > > Larry > -- > http://larry.masinter.net