From zedmaster@zedrock.com Wed Apr 1 01:14:16 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE0723A67A7 for ; Wed, 1 Apr 2009 01:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.831 X-Spam-Level: X-Spam-Status: No, score=0.831 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_50=0.001, HELO_EQ_BLUEYON=1.4, STOX_REPLY_TYPE=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 mibYNy3dQR-L for ; Wed, 1 Apr 2009 01:14:15 -0700 (PDT) Received: from smtp-out2.blueyonder.co.uk (smtp-out2.blueyonder.co.uk [195.188.213.5]) by core3.amsl.com (Postfix) with ESMTP id 9532D3A680B for ; Wed, 1 Apr 2009 01:14:15 -0700 (PDT) Received: from [172.23.170.147] (helo=anti-virus03-10) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1LovbN-0003PC-QS for mmox@ietf.org; Wed, 01 Apr 2009 09:15:13 +0100 Received: from [92.237.149.174] (helo=bumpydell) by asmtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1LovbN-0007No-9m for mmox@ietf.org; Wed, 01 Apr 2009 09:15:13 +0100 Message-ID: From: "zedmaster" To: References: Date: Wed, 1 Apr 2009 09:15:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [mmox] mmox Digest, Vol 2, Issue 121 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 08:14:16 -0000 The term "landmark" was used in some early VR systems - a landmark was just a "named" reference to a coordinate system - could be fixed or can be relative to another (potentially moving) object. Just like a hyperlink (favourite) you clicked on a landmark and you moved to that location. Tt was called "landmark" because these systems pre-dated web browsers, so there wasnt any notion of "favourite" at the time. Moving landmarks can be useful, but as you point out, you need to be careful as to where you anchor your landmark - in truth, you really should have set the landmark on the hotdog stall, not Coit Tower. The hotdog stall is more likely to be the moving target here, and if the hot dogs were that good, you'd want to visit that stall wherever he was located. -dirk ----- Original Message ----- >> >> Do we really want to use the term "landmark" in interop speak? >> That sounds a little too SL specific? Else, would you define what >> a "landmark" really means? >> >> >> >> The term "landmark" is in extremely wide use in many applications that >> involve maps or addresses, as well as in real life > > I know of no serious GIS application that uses the term. > > But the use in the real world is very different. In the real world, the > Coit Tower cannot move. In the virtual world, that's just a few mouse > clicks. If I had a delicious hot dog right next to the Coit Tower, and > the Coit Tower then moved, in real-world speak, the Coit Tower landmark > is no longer near anything it was near when I set that as a Landmark. > > In general, I like the term "address" more, because it's more akin to, > say, GPS coordinates. Also, when using Google Maps (arguably the most > used GIS system ever), they are called Favorites. > > But this brings up another use case point: Is the "landmark" referencing > an object (that can move), or an address (that can't)? And does it even > matter? Maybe these location favorites can simply be URLs with a known > type, and the actual words of the URL are specific to the system that > minted them. Then the only information that is important to the > destination system is: > 1) Knowing that this is a location URL, and not some other kind of URL > 2) Some user-visible description (icon, title, movie, sound, whatever) > for presentation > 3) The process by which one of these URLs get turned into an established > session From masinter@adobe.com Wed Apr 1 09:17:38 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBC1528C1E8 for ; Wed, 1 Apr 2009 09:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.124, 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 Nf666+WD9I4R for ; Wed, 1 Apr 2009 09:17:30 -0700 (PDT) Received: from psmtp.com (exprod6ob114.obsmtp.com [64.18.1.32]) by core3.amsl.com (Postfix) with ESMTP id 43F6428C1BF for ; Wed, 1 Apr 2009 09:17:28 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob114.postini.com ([64.18.5.12]) with SMTP ID DSNKSdOT1B89z+sgiw19czdzk6ZogT5nDyo2@postini.com; Wed, 01 Apr 2009 09:18:30 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n31GIPE0016587; Wed, 1 Apr 2009 09:18:25 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n31GIOiq009804; Wed, 1 Apr 2009 09:18:24 -0700 (PDT) Received: from excas02.corp.adobe.com (10.8.188.212) by nacas02.corp.adobe.com (10.8.189.100) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 1 Apr 2009 09:18:24 -0700 Received: from nambx04.corp.adobe.com ([10.8.127.98]) by excas02.corp.adobe.com ([10.8.188.212]) with mapi; Wed, 1 Apr 2009 09:18:23 -0700 From: Larry Masinter To: zedmaster , "mmox@ietf.org" Date: Wed, 1 Apr 2009 09:18:23 -0700 Thread-Topic: [mmox] mmox Digest, Vol 2, Issue 121 Thread-Index: AcmyogDT2aeqObG4Quujzj3xSpSoAQAOYXfg Message-ID: <8B62A039C620904E92F1233570534C9B0118CD4EE89B@nambx04.corp.adobe.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: multipart/alternative; boundary="_000_8B62A039C620904E92F1233570534C9B0118CD4EE89Bnambx04corp_" MIME-Version: 1.0 Subject: Re: [mmox] mmox Digest, Vol 2, Issue 121 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 16:17:38 -0000 --_000_8B62A039C620904E92F1233570534C9B0118CD4EE89Bnambx04corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable There has been extensive (really extensive) work on location information fr= ameworks in the IETF GEOPRIV area, including work on addressing moving targ= ets. It might be necessary to extend their data formats and look at their a= ctual deployment track record (so to speak) but please don't recapitulate t= he discussions without looking at the work. Location in virtual worlds would use different coordinate systems, of cours= e, but I'd think quite a bit of the extra infrastructure would be useful. http://www.ietf.org/html.charters/geopriv-charter.html which started in 2001. Internet-Drafts: Geolocation Policy: A Document Format for Expressing Privacy Preferences fo= r Location Information (55690 bytes) Carrying Location Objects in RADIUS and Diameter (124024 bytes) GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations (56575 bytes) Binary to Decimal Conversion for Location Configuration Information (17124 = bytes) GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requ= irements (39533 bytes) HTTP Enabled Location Delivery (HELD) (95495 bytes) Requirements for a Location-by-Reference Mechanism (32763 bytes) Discovering the Local Location Information Server (LIS) (44120 bytes) Dynamic Host Configuration Protocol (DHCP) Option for a Location Uniform Re= source Identifier (URI) (26128 bytes) Request For Comments: Geopriv requirements (RFC 3693) (68881= bytes) Threat Analysis of the geopriv Protocol (RFC 3694) (44364 bytes) Dynamic Host Configuration Protocol Option for Coordinate-based Location Co= nfiguration Information (RFC 3825) (31= 715 bytes) A Presence Architecture for the Distribution of GEOPRIV Location Objects (R= FC 4079) (16718 bytes) A Presence-based GEOPRIV Location Object Format (RFC 4119) (53522 bytes) updated by RFC 5139 Location Types Registry (RFC 4589) (24= 037 bytes) Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Ad= dresses Configuration Information (RFC 4676) (45208 bytes) obsoleted by RFC 4776 Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Ad= dresses Configuration Information (RFC 4776) (45495 bytes) obsoletes RFC 4676 Common Policy: A Document Format for Expressing Privacy Preferences (RFC 47= 45) (63602 bytes) Revised Civic Location Format for Presence Information Data Format Location= Object (PIDF-LO) (RFC 5139) (27470 by= tes) updates RFC 4119 Larry -- http://larry.masinter.net -----Original Message----- From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of zed= master Sent: Wednesday, April 01, 2009 1:15 AM To: mmox@ietf.org Subject: Re: [mmox] mmox Digest, Vol 2, Issue 121 The term "landmark" was used in some early VR systems - a landmark was just a "named" reference to a coordinate system - could be fixed or can be relative to another (potentially moving) object. Just like a hyperlink (favourite) you clicked on a landmark and you moved to that location. Tt was called "landmark" because these systems pre-dated web browsers, so ther= e wasnt any notion of "favourite" at the time. Moving landmarks can be useful, but as you point out, you need to be carefu= l as to where you anchor your landmark - in truth, you really should have set the landmark on the hotdog stall, not Coit Tower. The hotdog stall is more likely to be the moving target here, and if the hot dogs were that good, you'd want to visit that stall wherever he was located. -dirk ----- Original Message ----- >> >> Do we really want to use the term "landmark" in interop speak? >> That sounds a little too SL specific? Else, would you define what >> a "landmark" really means? >> >> >> >> The term "landmark" is in extremely wide use in many applications that >> involve maps or addresses, as well as in real life > > I know of no serious GIS application that uses the term. > > But the use in the real world is very different. In the real world, the > Coit Tower cannot move. In the virtual world, that's just a few mouse > clicks. If I had a delicious hot dog right next to the Coit Tower, and > the Coit Tower then moved, in real-world speak, the Coit Tower landmark > is no longer near anything it was near when I set that as a Landmark. > > In general, I like the term "address" more, because it's more akin to, > say, GPS coordinates. Also, when using Google Maps (arguably the most > used GIS system ever), they are called Favorites. > > But this brings up another use case point: Is the "landmark" referencing > an object (that can move), or an address (that can't)? And does it even > matter? Maybe these location favorites can simply be URLs with a known > type, and the actual words of the URL are specific to the system that > minted them. Then the only information that is important to the > destination system is: > 1) Knowing that this is a location URL, and not some other kind of URL > 2) Some user-visible description (icon, title, movie, sound, whatever) > for presentation > 3) The process by which one of these URLs get turned into an established > session _______________________________________________ mmox mailing list mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox --_000_8B62A039C620904E92F1233570534C9B0118CD4EE89Bnambx04corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

There has been extensive (really extensive) work on location information frameworks in the IETF GEOPRIV area, including work on addressing moving targets. It might be necessary to extend their data forma= ts and look at their actual deployment track record (so to speak) but please don't= recapitulate the discussions without looking at the work.

 

Location in virtual worlds would use different coor= dinate systems, of course, but I’d think quite a bit of the extra infrastruc= ture would be useful.

 

http://www.= ietf.org/html.charters/geopriv-charter.html

 

which started in 2001.

Internet-Drafts:

Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information (55690 bytes)
Carrying Location Objects in RADIUS and Diameter (124024 bytes)
GEOPRIV PIDF-LO Usage Clarification, Considerations and Recommendations (56575 bytes)
Binary to Decimal Conversion for Location Configuration Information (17124 byt= es)
GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and Requirements= (39533 bytes)
HTTP Enabled Location Delivery (HELD) (95495 bytes)
Requirements for a Location-by-Reference Mechanism (32763 bytes)
Discovering the Local Location Information Server (LIS) (44120 bytes)
Dynamic Host Configuration Protocol (DHCP) Option for a Location Uniform Resource Identifier (URI) (26128 bytes)

Request For Comments:

Geo= priv requirements (RFC 3693) (68881 bytes)
Threat Analysis of the geop= riv Protocol (RFC 3694) (44364 bytes)
Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information (RF= C 3825) (31715 bytes)
A Presence Architecture for= the Distribution of GEOPRIV Location Objects (RFC 4079) (16718 bytes)
A Presence-based GEOPRIV Lo= cation Object Format (RFC 4119) (53522 bytes) upd= ated by RFC 5139
Location Types Registry (RF= C 4589) (24037 bytes)
Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information (RFC 4676) (45208 bytes) obsolete= d by RFC 4776
Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information (RFC 4776) (45495 bytes) obsol= etes RFC 4676
Common Policy: A Document F= ormat for Expressing Privacy Preferences (RFC 4745) (63602 bytes)
Revised Civic Location Form= at for Presence Information Data Format Location Object (PIDF-LO) (RFC 5139) (27470 bytes) updates RFC 4119

 

Larry

--

http://larry.masinter.net

 

 

-----Original Message-----
From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of zed= master
Sent: Wednesday, April 01, 2009 1:15 AM
To: mmox@ietf.org
Subject: Re: [mmox] mmox Digest, Vol 2, Issue 121

 

The term "landmark" was used in some earl= y VR systems - a landmark was just

a "named" reference to a coordinate syste= m - could be fixed or can be

relative to another (potentially moving) object.&nb= sp; Just like a hyperlink

(favourite) you clicked on a landmark and you moved= to that location.  Tt

was called "landmark" because these syste= ms pre-dated web browsers, so there

wasnt any notion of "favourite" at the ti= me.

 

Moving landmarks can be useful, but as you point ou= t, you need to be careful

as to where you anchor your landmark - in truth, yo= u really should have set

the landmark on the hotdog stall, not Coit Tower.&n= bsp; The hotdog stall is more

likely to be the moving target here, and if the hot= dogs were that good,

you'd want to visit that stall wherever he was loca= ted.

 

-dirk

 

 

----- Original Message -----

>> 

>>     Do we really want = to use the term "landmark" in interop speak?

>>     That sounds a litt= le too SL specific? Else, would you define what

>>     a "landmark&q= uot; really means?

>> 

>> 

>> 

>> The term "landmark" is in extrem= ely wide use in many applications that

>> involve maps or addresses, as well as in r= eal life

> 

> I know of no serious GIS application that uses= the term.

> 

> But the use in the real world is very differen= t. In the real world, the

> Coit Tower cannot move. In the virtual world, = that's just a few mouse

> clicks. If I had a delicious hot dog right nex= t to the Coit Tower, and

> the Coit Tower then moved, in real-world speak= , the Coit Tower landmark

> is no longer near anything it was near when I = set that as a Landmark.

> 

> In general, I like the term "address"= ; more, because it's more akin to,

> say, GPS coordinates. Also, when using Google = Maps (arguably the most

> used GIS system ever), they are called Favorit= es.

> 

> But this brings up another use case point: Is = the "landmark" referencing

> an object (that can move), or an address (that can't)? And does it even

> matter? Maybe these location favorites can sim= ply be URLs with a known

> type, and the actual words of the URL are spec= ific to the system that

> minted them. Then the only information that is important to the

> destination system is:

> 1) Knowing that this is a location URL, and no= t some other kind of URL

> 2) Some user-visible description (icon, title, movie, sound, whatever)

> for presentation

> 3) The process by which one of these URLs get = turned into an established

> session

 

 

_______________________________________________

mmox mailing list

mmox@ietf.org

https://www.ietf.org/mailman/listinfo/mmox

--_000_8B62A039C620904E92F1233570534C9B0118CD4EE89Bnambx04corp_-- From jwatte@gmail.com Wed Apr 1 09:58:30 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEDB228C12D for ; Wed, 1 Apr 2009 09:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 H8vaxjdLvME4 for ; Wed, 1 Apr 2009 09:58:29 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by core3.amsl.com (Postfix) with ESMTP id 51A2A3A68C0 for ; Wed, 1 Apr 2009 09:58:29 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so101785rvb.49 for ; Wed, 01 Apr 2009 09:59:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=EE4zDGmQzUYKNJH/1JM59oGc/i8W7uUCMUks8zJuV20=; b=dp3bkQAnnGZv9a8Z4VIY2AlTFegz1PYCvdFISGEj9J7zSE1ud8Tv1aSDFh2XoMAOKi 4eRSh4E99CMUWQyOyl9mav7fhqXThVZaEsQX0ljixCrbYcqrXJl4G0FbgognuMsCptpK RUWatvVq4tH6OtZWxLxq7KUGCBvUM0mYGiX2k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=tqXYwlzS9M+yzaSqmnLxOmzvZphPXOZSOQfGu8PinM1EjMDp6ploE+hdLiPtRmzUTb Dk7qeVd7vGI3F1bwTK0eQ1aoYJNeJ6MRRr/yFmZ2/WtiyXrcp20BUX5dw720KWWqqQ+U PskDZmC/2dQl75r3YaWHmQGfl4fMT+Y1ZddgY= Received: by 10.140.157.1 with SMTP id f1mr4101012rve.196.1238605169823; Wed, 01 Apr 2009 09:59:29 -0700 (PDT) Received: from ?10.10.111.233? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id g14sm336282rvb.9.2009.04.01.09.59.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 01 Apr 2009 09:59:29 -0700 (PDT) Message-ID: <49D39D70.8020600@gmail.com> Date: Wed, 01 Apr 2009 09:59:28 -0700 From: Jon Watte User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Larry Masinter References: <8B62A039C620904E92F1233570534C9B0118CD4EE89B@nambx04.corp.adobe.com> In-Reply-To: <8B62A039C620904E92F1233570534C9B0118CD4EE89B@nambx04.corp.adobe.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "mmox@ietf.org" , zedmaster Subject: Re: [mmox] mmox Digest, Vol 2, Issue 121 X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 16:58:30 -0000 Some of this is pretty good. Some of it isn't quite, though, because while there is only one Earth, there are zillions of different, sometimes-connected virtual worlds. Even the people doing real-world terrain may want to do different version of the real-world terrain. If the LAPD is running an anti-terrorist exercise, and Paramount Pictures are planning a low-flying helicopter chase, they might be in the same physical coordinate space, but want to actually be in different logical coordinate spaces. That being said, I agree: let's learn from the past and use what's already in the IETF. Sincerely, jw Larry Masinter wrote: > > There has been extensive (really extensive) work on location > information frameworks in the IETF GEOPRIV area, including work on > addressing moving targets. It might be necessary to extend their data > formats and look at their actual deployment track record (so to speak) > but please don't recapitulate the discussions without looking at the work. > > Location in virtual worlds would use different coordinate systems, of > course, but I’d think quite a bit of the extra infrastructure would be > useful. > > http://www.ietf.org/html.charters/geopriv-charter.html > > which started in 2001. > > > Internet-Drafts: > > Geolocation Policy: A Document Format for Expressing Privacy > Preferences for Location Information > (55690 > bytes) > Carrying Location Objects in RADIUS and Diameter > (124024 > bytes) > GEOPRIV PIDF-LO Usage Clarification, Considerations and > Recommendations > (56575 > bytes) > Binary to Decimal Conversion for Location Configuration Information > (17124 > bytes) > GEOPRIV Layer 7 Location Configuration Protocol; Problem Statement and > Requirements > (39533 > bytes) > HTTP Enabled Location Delivery (HELD) > (95495 > bytes) > Requirements for a Location-by-Reference Mechanism > (32763 > bytes) > Discovering the Local Location Information Server (LIS) > (44120 > bytes) > Dynamic Host Configuration Protocol (DHCP) Option for a Location > Uniform Resource Identifier (URI) > (26128 > bytes) > > > Request For Comments: > > Geopriv requirements (RFC 3693) > (68881 bytes) > Threat Analysis of the geopriv Protocol (RFC 3694) > (44364 bytes) > Dynamic Host Configuration Protocol Option for Coordinate-based > Location Configuration Information (RFC 3825) > (31715 bytes) > A Presence Architecture for the Distribution of GEOPRIV Location > Objects (RFC 4079) (16718 bytes) > A Presence-based GEOPRIV Location Object Format (RFC 4119) > (53522 bytes) updated by RFC 5139 > Location Types Registry (RFC 4589) > (24037 bytes) > Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for > Civic Addresses Configuration Information (RFC 4676) > (45208 bytes) obsoleted by RFC 4776 > Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for > Civic Addresses Configuration Information (RFC 4776) > (45495 bytes) obsoletes RFC 4676 > Common Policy: A Document Format for Expressing Privacy Preferences > (RFC 4745) (63602 bytes) > Revised Civic Location Format for Presence Information Data Format > Location Object (PIDF-LO) (RFC 5139) > (27470 bytes) updates RFC 4119 > > Larry > > -- > > http://larry.masinter.net > > -----Original Message----- > From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf > Of zedmaster > Sent: Wednesday, April 01, 2009 1:15 AM > To: mmox@ietf.org > Subject: Re: [mmox] mmox Digest, Vol 2, Issue 121 > > The term "landmark" was used in some early VR systems - a landmark was > just > > a "named" reference to a coordinate system - could be fixed or can be > > relative to another (potentially moving) object. Just like a hyperlink > > (favourite) you clicked on a landmark and you moved to that location. Tt > > was called "landmark" because these systems pre-dated web browsers, so > there > > wasnt any notion of "favourite" at the time. > > Moving landmarks can be useful, but as you point out, you need to be > careful > > as to where you anchor your landmark - in truth, you really should > have set > > the landmark on the hotdog stall, not Coit Tower. The hotdog stall is > more > > likely to be the moving target here, and if the hot dogs were that good, > > you'd want to visit that stall wherever he was located. > > -dirk > > ----- Original Message ----- > > >> > > >> Do we really want to use the term "landmark" in interop speak? > > >> That sounds a little too SL specific? Else, would you define what > > >> a "landmark" really means? > > >> > > >> > > >> > > >> The term "landmark" is in extremely wide use in many applications that > > >> involve maps or addresses, as well as in real life > > > > > > I know of no serious GIS application that uses the term. > > > > > > But the use in the real world is very different. In the real world, the > > > Coit Tower cannot move. In the virtual world, that's just a few mouse > > > clicks. If I had a delicious hot dog right next to the Coit Tower, and > > > the Coit Tower then moved, in real-world speak, the Coit Tower landmark > > > is no longer near anything it was near when I set that as a Landmark. > > > > > > In general, I like the term "address" more, because it's more akin to, > > > say, GPS coordinates. Also, when using Google Maps (arguably the most > > > used GIS system ever), they are called Favorites. > > > > > > But this brings up another use case point: Is the "landmark" referencing > > > an object (that can move), or an address (that can't)? And does it even > > > matter? Maybe these location favorites can simply be URLs with a known > > > type, and the actual words of the URL are specific to the system that > > > minted them. Then the only information that is important to the > > > destination system is: > > > 1) Knowing that this is a location URL, and not some other kind of URL > > > 2) Some user-visible description (icon, title, movie, sound, whatever) > > > for presentation > > > 3) The process by which one of these URLs get turned into an established > > > session > > _______________________________________________ > > mmox mailing list > > mmox@ietf.org > > https://www.ietf.org/mailman/listinfo/mmox > > ------------------------------------------------------------------------ > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From john.hurliman@intel.com Wed Apr 1 13:56:04 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6927E3A6BAB for ; Wed, 1 Apr 2009 13:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.126 X-Spam-Level: X-Spam-Status: No, score=-6.126 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] 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 NGtgGqNRLHh7 for ; Wed, 1 Apr 2009 13:56:03 -0700 (PDT) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by core3.amsl.com (Postfix) with ESMTP id A868A3A6DA6 for ; Wed, 1 Apr 2009 13:56:03 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 01 Apr 2009 13:48:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.39,308,1235980800"; d="scan'208";a="444115963" Received: from rrsmsx603.amr.corp.intel.com ([10.31.0.57]) by fmsmga002.fm.intel.com with ESMTP; 01 Apr 2009 13:52:19 -0700 Received: from rrsmsx601.amr.corp.intel.com (10.31.0.151) by rrsmsx603.amr.corp.intel.com (10.31.0.57) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 1 Apr 2009 14:56:46 -0600 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Wed, 1 Apr 2009 14:56:46 -0600 From: "Hurliman, John" To: "mmox@ietf.org" Date: Wed, 1 Apr 2009 14:56:41 -0600 Thread-Topic: OGP scalability concerns Thread-Index: AcmzDFuLPSSoNG5USN2irBnDmPgnbQ== Message-ID: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {6368C765-7EB1-4683-B9A2-20A01E3859F9} x-cr-hashedpuzzle: ZsI= AdFq Ak6Q BpGA DzqU D/kZ ExyI E5/0 FNWU Ff2E F48d GOJg GXhM IX0l IaEh Jn2A; 1; bQBtAG8AeABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {6368C765-7EB1-4683-B9A2-20A01E3859F9}; agBvAGgAbgAuAGgAdQByAGwAaQBtAGEAbgBAAGkAbgB0AGUAbAAuAGMAbwBtAA==; Wed, 01 Apr 2009 20:56:41 GMT;TwBHAFAAIABzAGMAYQBsAGEAYgBpAGwAaQB0AHkAIABjAG8AbgBjAGUAcgBuAHMA acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 20:56:04 -0000 A few days ago I posted an e-mail highlighting my concerns with the archite= cture of OGP. I'm not sure if there was an implicit agreement from the OGP = authors or if the e-mail was lost in the flood. I'm reposting in a new thre= ad because I want to make sure I have a proper understanding of the archite= cture. >* Indirectly, it highlights that the Agent Domain model does not >have a solution to the problem of accessing worlds with which there is=20 >no trust agreement. People will want to enter arbitrary worlds, and=20 >therefore that restriction is inadequate. >* There will be millions of worlds in an Internet-scale metaverse, >which makes the concept of interop through trust agreements far too=20 >narrow. Trust loses its meaning entirely when scaled to millions,=20 >becoming mere paperwork or "security theater". =20 This is, in my opinion, the fundamental flaw in OGP. Explicit trust maps (w= hitelists) work great when IBM wants to define policy to connect to the Lin= den Lab grid, but has no meaning and no hope of scaling when you talk about= defining trust for millions of simulation grids and millions (or at least = thousands) of identity providers. This is the primary reason that Intel and= many members of the OpenSimulator/OpenMetaverse community have not conside= red OGP as a strong proposal for virtual world interoperability. If this un= derstanding is not accurate, it would be helpful if an OGP author could ste= p in and clear up the confusion. John From morgaine.dinova@googlemail.com Wed Apr 1 15:36:29 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC5153A6903 for ; Wed, 1 Apr 2009 15:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.73 X-Spam-Level: X-Spam-Status: No, score=-1.73 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] 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 4+TVB4Wx+b7p for ; Wed, 1 Apr 2009 15:36:28 -0700 (PDT) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id 231773A67B6 for ; Wed, 1 Apr 2009 15:36:27 -0700 (PDT) Received: by ewy9 with SMTP id 9so288174ewy.37 for ; Wed, 01 Apr 2009 15:37: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=czG/yiJA4SEOOUNNKm9tdT/3KkkZ2NVQvPQYspHBH+E=; b=Q4QWZomrRc30rGZI0di2C4kjXz83WKh1uQIftYN0WJ+Ph2oLJJdq967PneMfqz8d/G 7ZnbNeaoBzfqh0QPHlYXGO2Y2hmP7dtLqh5wS06lV9r6sN57miO4OxVedSx8MjkAavCs HluDWlekP4fK9mq7qpzgwjlV+vaxcgJl4AkBI= 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=CK9j/yTk1PL8IP4W107WMnFwtgWHE66nKGTIEbdeUx1WYDI4L/S47lY4jezedGRe9m oIVf2ZDjUvhu+rTWBkEa0xcujEY+O7zwa/zWbk/k4fwbps//aXFc6NfZxeyu5/LowUgS VCsru/OVnUpxTY1ZyMhrzSz0j/elUdQF/wQao= MIME-Version: 1.0 Received: by 10.216.28.198 with SMTP id g48mr2823724wea.109.1238625447716; Wed, 01 Apr 2009 15:37:27 -0700 (PDT) In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> Date: Wed, 1 Apr 2009 23:37:27 +0100 Message-ID: From: Morgaine To: "Hurliman, John" Content-Type: multipart/alternative; boundary=0016e6db5c0cd2299e046685f54a Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 22:36:29 -0000 --0016e6db5c0cd2299e046685f54a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Wed, Apr 1, 2009 at 9:56 PM, Hurliman, John wrote: A few days ago I posted an e-mail highlighting my concerns with the > architecture of OGP. I'm not sure if there was an implicit agreement from > the OGP authors or if the e-mail was lost in the flood. I'm reposting in a > new thread because I want to make sure I have a proper understanding of the > architecture. > > John, I don't think that it indicates implicit agreement nor that your post was lost in the flood. It's more a reflection of the fact that we've not had a single comment from OGP designers at all here since the BoF, on *any*topic. :-) I'm not sure where they've got to, but they're not engaging in technical discussions with the list at this time. You haven't missed any responses, afaik. ;-) Morgaine. On Wed, Apr 1, 2009 at 9:56 PM, Hurliman, John wrote: > A few days ago I posted an e-mail highlighting my concerns with the > architecture of OGP. I'm not sure if there was an implicit agreement from > the OGP authors or if the e-mail was lost in the flood. I'm reposting in a > new thread because I want to make sure I have a proper understanding of the > architecture. > > > >* Indirectly, it highlights that the Agent Domain model does not > >have a solution to the problem of accessing worlds with which there is > >no trust agreement. People will want to enter arbitrary worlds, and > >therefore that restriction is inadequate. > >* There will be millions of worlds in an Internet-scale metaverse, > >which makes the concept of interop through trust agreements far too > >narrow. Trust loses its meaning entirely when scaled to millions, > >becoming mere paperwork or "security theater". > > This is, in my opinion, the fundamental flaw in OGP. Explicit trust maps > (whitelists) work great when IBM wants to define policy to connect to the > Linden Lab grid, but has no meaning and no hope of scaling when you talk > about defining trust for millions of simulation grids and millions (or at > least thousands) of identity providers. This is the primary reason that > Intel and many members of the OpenSimulator/OpenMetaverse community have not > considered OGP as a strong proposal for virtual world interoperability. If > this understanding is not accurate, it would be helpful if an OGP author > could step in and clear up the confusion. > > John > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > --0016e6db5c0cd2299e046685f54a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 1, 2009 at 9:56 PM, Hurliman, John <= span dir=3D"ltr"><john.hurlim= an@intel.com> wrote:

A few days ago I posted an e-mail highlighting my concerns with the architecture of OGP. I'm not sure if there was an implicit agreement from the OGP authors or if the e-mail was lost in the flood. I'm reposting in a new thread because I want to make sure I have a proper understanding of the architecture.


John, I don't think that it indicates implicit ag= reement nor that your post was lost in the flood.=A0 It's more a reflec= tion of the fact that we've not had a single comment from OGP designers= at all here since the BoF, on any topic. :-)

I'm not sure where they've got to, but they're not engaging= in technical discussions with the list at this time.=A0 You haven't mi= ssed any responses, afaik. ;-)

Morgaine.









On Wed, Apr 1, 2009 at 9= :56 PM, Hurliman, John <john.hurliman@intel.com> wrote:
A few days ago I posted an e-mail highlighting my concerns with the archite= cture of OGP. I'm not sure if there was an implicit agreement from the = OGP authors or if the e-mail was lost in the flood. I'm reposting in a = new thread because I want to make sure I have a proper understanding of the= architecture.


>* =A0 =A0 =A0Indirectly, it highlights that the Agent Domain model does= not
>have a solution to the problem of accessing worlds with which there is<= br> >no trust agreement. =A0People will want to enter arbitrary worlds, and<= br> >therefore that restriction is inadequate.
>* =A0 =A0 =A0There will be millions of worlds in an Internet-scale meta= verse,
>which makes the concept of interop through trust agreements far too
>narrow. =A0Trust loses its meaning entirely when scaled to millions, >becoming mere paperwork or "security theater".

This is, in my opinion, the fundamental flaw in OGP. Explicit trust maps (w= hitelists) work great when IBM wants to define policy to connect to the Lin= den Lab grid, but has no meaning and no hope of scaling when you talk about= defining trust for millions of simulation grids and millions (or at least = thousands) of identity providers. This is the primary reason that Intel and= many members of the OpenSimulator/OpenMetaverse community have not conside= red OGP as a strong proposal for virtual world interoperability. If this un= derstanding is not accurate, it would be helpful if an OGP author could ste= p in and clear up the confusion.

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

--0016e6db5c0cd2299e046685f54a-- From infinity@lindenlab.com Wed Apr 1 16:52:29 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73F813A6B92 for ; Wed, 1 Apr 2009 16:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.373 X-Spam-Level: X-Spam-Status: No, score=-3.373 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 qne5EAiNgrEk for ; Wed, 1 Apr 2009 16:52:26 -0700 (PDT) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 549F73A6A28 for ; Wed, 1 Apr 2009 16:52:26 -0700 (PDT) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 6B5923DBC06B; Wed, 1 Apr 2009 16:53:26 -0700 (PDT) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: "Hurliman, John" In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 1 Apr 2009 16:53:26 -0700 References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 23:52:29 -0000 On Apr 1, 2009, at 1:56 PM, Hurliman, John wrote: > A few days ago I posted an e-mail highlighting my concerns with the > architecture of OGP. I'm not sure if there was an implicit agreement > from the OGP authors or if the e-mail was lost in the flood. I'm > reposting in a new thread because I want to make sure I have a > proper understanding of the architecture. > > >> * Indirectly, it highlights that the Agent Domain model does not >> have a solution to the problem of accessing worlds with which there >> is >> no trust agreement. People will want to enter arbitrary worlds, and >> therefore that restriction is inadequate. i would guess the solution would be to have a promiscuous agent domain that has a "i will trust all worlds" settings. i think this is a limitation of the implementation, not the architecture. >> * There will be millions of worlds in an Internet-scale metaverse, >> which makes the concept of interop through trust agreements far too >> narrow. Trust loses its meaning entirely when scaled to millions, >> becoming mere paperwork or "security theater". +1. what's your suggestion? > > This is, in my opinion, the fundamental flaw in OGP. Explicit trust > maps (whitelists) work great when IBM wants to define policy to > connect to the Linden Lab grid, but has no meaning and no hope of > scaling when you talk about defining trust for millions of > simulation grids and millions (or at least thousands) of identity > providers. This is the primary reason that Intel and many members of > the OpenSimulator/OpenMetaverse community have not considered OGP as > a strong proposal for virtual world interoperability. If this > understanding is not accurate, it would be helpful if an OGP author > could step in and clear up the confusion. > > John > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From charles.krinke@gmail.com Wed Apr 1 17:00:15 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C6B13A6B48 for ; Wed, 1 Apr 2009 17:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] 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 s5vepP3s7ArJ for ; Wed, 1 Apr 2009 17:00:14 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by core3.amsl.com (Postfix) with ESMTP id A9F433A69A9 for ; Wed, 1 Apr 2009 17:00:13 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d11so275588and.4 for ; Wed, 01 Apr 2009 17:01: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; bh=RgrUgawxHFrTpypWVDleehW3BVoiw/pj7r3yM0PWAgw=; b=ANeJIC1VEmZ8BtK9G5xX5kVdVQPyfMOqTOJdLSDaWOD+zqW7yrlFkHo6stuZCR4LPL H724vcw9LQjZk8v7Ton0i3gKmB8Th/Jw8lmukW5isQyYYc1voRxO31W2GolPbwOEesFl vXwOhwAL/Mv3Gv6LSt8a/6q3nyi0ZEOLUBklg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=cIt5VMCSM9CuiXa5JqDLuHLbfm0At8o15N6WarRAZGzGd6YtYnza9vZ1zroZzkVEu1 pB/vKf3vgffR/DPGM0w0HTp4U60TWtOgSeTieItby4fVH8DW9HDFKctep+APzuVHL1gT VZudN6KBh3dmW38r7GltYomF2XI7s+5UOIq/U= MIME-Version: 1.0 Received: by 10.100.11.14 with SMTP id 14mr7633876ank.89.1238630474209; Wed, 01 Apr 2009 17:01:14 -0700 (PDT) In-Reply-To: References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> Date: Wed, 1 Apr 2009 16:01:14 -0800 Message-ID: From: Charles Krinke To: "Meadhbh Hamrick (Infinity)" Content-Type: multipart/alternative; boundary=0016e642dd646c5c90046687211c Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 00:00:15 -0000 --0016e642dd646c5c90046687211c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit To me, interop implies a full handoff of an avatar from one virtual world to another. I can appreciate OGP offering one half of this in its current form in a teleport from a SecondLife type grid to an OpenSim type grid. But, we also need to consider how a citizen of an OpenSim grid can teleport to a SecondLife grid as well. In the case of OpenSim grids, we have a UserServer as opposed to an AgentDomain, but they offer a similar set of services. So, from the MMOX viewpoint, we could perhaps get there from here if we were to consider the fact that each side of this teleport needs to be treated in an equal and sovereign manner. To me, interop between grids is more of a "border crossing & customs" paradigm. That is, each grid may have its own border crossing rules for exit and its own customs rules for entry and each is sovereign in its own right. That is, there is no overwhelming AgentDomain that controls all teleports between all grids, but rather an AgentDomain is a paradigm for one particular grid, or in the SecondLife case, for a few SecondLife grids all under the control of one corporate personality. Charles Krinke OpenSim Core Developer OSGrid Director On Wed, Apr 1, 2009 at 3:53 PM, Meadhbh Hamrick (Infinity) < infinity@lindenlab.com> wrote: > > On Apr 1, 2009, at 1:56 PM, Hurliman, John wrote: > > A few days ago I posted an e-mail highlighting my concerns with the >> architecture of OGP. I'm not sure if there was an implicit agreement from >> the OGP authors or if the e-mail was lost in the flood. I'm reposting in a >> new thread because I want to make sure I have a proper understanding of the >> architecture. >> >> >> * Indirectly, it highlights that the Agent Domain model does not >>> have a solution to the problem of accessing worlds with which there is >>> no trust agreement. People will want to enter arbitrary worlds, and >>> therefore that restriction is inadequate. >>> >> > i would guess the solution would be to have a promiscuous agent domain that > has a "i will trust all worlds" settings. i think this is a limitation of > the implementation, not the architecture. > > * There will be millions of worlds in an Internet-scale metaverse, >>> which makes the concept of interop through trust agreements far too >>> narrow. Trust loses its meaning entirely when scaled to millions, >>> becoming mere paperwork or "security theater". >>> >> > +1. what's your suggestion? > > > >> This is, in my opinion, the fundamental flaw in OGP. Explicit trust maps >> (whitelists) work great when IBM wants to define policy to connect to the >> Linden Lab grid, but has no meaning and no hope of scaling when you talk >> about defining trust for millions of simulation grids and millions (or at >> least thousands) of identity providers. This is the primary reason that >> Intel and many members of the OpenSimulator/OpenMetaverse community have not >> considered OGP as a strong proposal for virtual world interoperability. If >> this understanding is not accurate, it would be helpful if an OGP author >> could step in and clear up the confusion. >> >> John >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > -- Charles Krinke OpenSim Core Developer OSGrid Director --0016e642dd646c5c90046687211c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To me, interop implies a full handoff of an avatar from one virtual world t= o another.

I can appreciate OGP offering one half of this in its cu= rrent form in a teleport from a SecondLife type grid to an OpenSim type gri= d. But, we also need to consider how a citizen of an OpenSim grid can telep= ort to a SecondLife grid as well.

In the case of OpenSim grids, we have a UserServer as opposed to an Age= ntDomain, but they offer a similar set of services.

So, from the MMO= X viewpoint, we could perhaps get there from here if we were to consider th= e fact that each side of this teleport needs to be treated in an equal and = sovereign manner.

To me, interop between grids is more of a "border crossing & c= ustoms" paradigm. That is, each grid may have its own border crossing = rules for exit and its own customs rules for entry and each is sovereign in= its own right. That is, there is no overwhelming AgentDomain that controls= all teleports between all grids, but rather an AgentDomain is a paradigm f= or one particular grid, or in the SecondLife case, for a few SecondLife gri= ds all under the control of one corporate personality.

Charles Krinke
OpenSim Core Developer
OSGrid Director


=

On Wed, Apr 1, 2009 at 3:53 PM, Meadhbh = Hamrick (Infinity) <infinity@lindenlab.com> wrote:

On Apr 1, 2009, at 1:56 PM, Hurliman, John wrote:

A few days ago I posted an e-mail highlighting my concerns with the archite= cture of OGP. I'm not sure if there was an implicit agreement from the = OGP authors or if the e-mail was lost in the flood. I'm reposting in a = new thread because I want to make sure I have a proper understanding of the= architecture.


* =C2=A0 =C2=A0 =C2=A0 Indirectly, it highlights that the Agent Domain mode= l does not
have a solution to the problem of accessing worlds with which there is
no trust agreement. =C2=A0People will want to enter arbitrary worlds, and therefore that restriction is inadequate.

i would guess the solution would be to have a promiscuous agent domain that= has a "i will trust all worlds" settings. i think this is a limi= tation of the implementation, not the architecture.

* =C2=A0 =C2=A0 =C2=A0 There will be millions of worlds in an Internet-scal= e metaverse,

which makes the concept of interop through trust agreements far too
narrow. =C2=A0Trust loses its meaning entirely when scaled to millions,
becoming mere paperwork or "security theater".

+1. what's your suggestion?



This is, in my opinion, the fundamental flaw in OGP. Explicit trust maps (w= hitelists) work great when IBM wants to define policy to connect to the Lin= den Lab grid, but has no meaning and no hope of scaling when you talk about= defining trust for millions of simulation grids and millions (or at least = thousands) of identity providers. This is the primary reason that Intel and= many members of the OpenSimulator/OpenMetaverse community have not conside= red OGP as a strong proposal for virtual world interoperability. If this un= derstanding is not accurate, it would be helpful if an OGP author could ste= p in and clear up the confusion.

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

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



--
Charles Kri= nke
OpenSim Core Developer
OSGrid Director
--0016e642dd646c5c90046687211c-- From infinity@lindenlab.com Wed Apr 1 17:05:56 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3EC93A6B48 for ; Wed, 1 Apr 2009 17:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.371 X-Spam-Level: X-Spam-Status: No, score=-3.371 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 FbjqkGUdQuOz for ; Wed, 1 Apr 2009 17:05:55 -0700 (PDT) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id CAD7D3A67D4 for ; Wed, 1 Apr 2009 17:05:54 -0700 (PDT) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id D7BCE3DBC446; Wed, 1 Apr 2009 17:06:55 -0700 (PDT) Message-Id: <15D13F31-B787-4FE5-AEF0-B45F7AB4CCDB@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Morgaine In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-9-478094337 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 1 Apr 2009 17:06:55 -0700 References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 00:05:57 -0000 --Apple-Mail-9-478094337 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit sheesh. you miss one awg meeting and you're branded a deserter! but yes... Robla, Zero and I spent most of our week last week at the IETF meeting. fwiw... we had more to chat about there than MMOX, which is why we weren't online much in the latter part of the week. And... being gone from the office for a week allows a bunch of stuff to pile up, which is why i've been very nearly completely unreachable (mea culpa.) I suspect the situation is radically similar for Zero. -cheers -opt 5 On Apr 1, 2009, at 3:37 PM, Morgaine wrote: > On Wed, Apr 1, 2009 at 9:56 PM, Hurliman, John > wrote: > > A few days ago I posted an e-mail highlighting my concerns with the > architecture of OGP. I'm not sure if there was an implicit agreement > from the OGP authors or if the e-mail was lost in the flood. I'm > reposting in a new thread because I want to make sure I have a > proper understanding of the architecture. > > > John, I don't think that it indicates implicit agreement nor that > your post was lost in the flood. It's more a reflection of the fact > that we've not had a single comment from OGP designers at all here > since the BoF, on any topic. :-) > > I'm not sure where they've got to, but they're not engaging in > technical discussions with the list at this time. You haven't > missed any responses, afaik. ;-) > > Morgaine. > > > > > > > > > > On Wed, Apr 1, 2009 at 9:56 PM, Hurliman, John > wrote: > A few days ago I posted an e-mail highlighting my concerns with the > architecture of OGP. I'm not sure if there was an implicit agreement > from the OGP authors or if the e-mail was lost in the flood. I'm > reposting in a new thread because I want to make sure I have a > proper understanding of the architecture. > > > >* Indirectly, it highlights that the Agent Domain model does not > >have a solution to the problem of accessing worlds with which there > is > >no trust agreement. People will want to enter arbitrary worlds, and > >therefore that restriction is inadequate. > >* There will be millions of worlds in an Internet-scale > metaverse, > >which makes the concept of interop through trust agreements far too > >narrow. Trust loses its meaning entirely when scaled to millions, > >becoming mere paperwork or "security theater". > > This is, in my opinion, the fundamental flaw in OGP. Explicit trust > maps (whitelists) work great when IBM wants to define policy to > connect to the Linden Lab grid, but has no meaning and no hope of > scaling when you talk about defining trust for millions of > simulation grids and millions (or at least thousands) of identity > providers. This is the primary reason that Intel and many members of > the OpenSimulator/OpenMetaverse community have not considered OGP as > a strong proposal for virtual world interoperability. If this > understanding is not accurate, it would be helpful if an OGP author > could step in and clear up the confusion. > > John > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --Apple-Mail-9-478094337 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable sheesh. you miss one awg = meeting and you're branded a deserter!

but yes... = Robla, Zero and I spent most of our week last week at the IETF meeting. = fwiw... we had more to chat about there than MMOX, which is why we = weren't online much in the latter part of the week. And... being gone = from the office for a week allows a bunch of stuff to pile up, which is = why i've been very nearly completely unreachable (mea culpa.) I suspect = the situation is radically similar for = Zero.

-cheers
-opt = 5

On Apr 1, 2009, at 3:37 PM, Morgaine = wrote:

On Wed, Apr 1, 2009 at 9:56 PM, = Hurliman, John <john.hurliman@intel.com> wrote:

A few days ago I posted an e-mail highlighting my concerns with = the architecture of OGP. I'm not sure if there was an implicit agreement = from the OGP authors or if the e-mail was lost in the flood. I'm = reposting in a new thread because I want to make sure I have a proper = understanding of the architecture.


John, = I don't think that it indicates implicit agreement nor that your post = was lost in the flood.  It's more a reflection of the fact that = we've not had a single comment from OGP designers at all here since the = BoF, on any topic. :-)

I'm not sure where they've got to, = but they're not engaging in technical discussions with the list at this = time.  You haven't missed any responses, afaik. = ;-)

Morgaine.



=





On Wed, Apr 1, 2009 = at 9:56 PM, Hurliman, John <john.hurliman@intel.com> wrote:
A few days ago I posted an e-mail highlighting my concerns with = the architecture of OGP. I'm not sure if there was an implicit agreement = from the OGP authors or if the e-mail was lost in the flood. I'm = reposting in a new thread because I want to make sure I have a proper = understanding of the architecture.


>*     =  Indirectly, it highlights that the Agent Domain model does not
= >have a solution to the problem of accessing worlds with which there = is
>no trust agreement.  People will want to enter arbitrary = worlds, and
>therefore that restriction is inadequate.
>* =      There will be millions of worlds in an = Internet-scale metaverse,
>which makes the concept of interop = through trust agreements far too
>narrow.  Trust loses its = meaning entirely when scaled to millions,
>becoming mere = paperwork or "security theater".

This is, in my opinion, the = fundamental flaw in OGP. Explicit trust maps (whitelists) work great = when IBM wants to define policy to connect to the Linden Lab grid, but = has no meaning and no hope of scaling when you talk about defining trust = for millions of simulation grids and millions (or at least thousands) of = identity providers. This is the primary reason that Intel and many = members of the OpenSimulator/OpenMetaverse community have not considered = OGP as a strong proposal for virtual world interoperability. If this = understanding is not accurate, it would be helpful if an OGP author = could step in and clear up the confusion.

John
= _______________________________________________
mmox mailing = list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox
=

= _______________________________________________
mmox mailing = list
mmox@ietf.org
https://www.ietf.org/ma= ilman/listinfo/mmox

= --Apple-Mail-9-478094337-- From infinity@lindenlab.com Wed Apr 1 17:29:25 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE5BD3A6A28 for ; Wed, 1 Apr 2009 17:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.369 X-Spam-Level: X-Spam-Status: No, score=-3.369 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 igDRTwIaFHdx for ; Wed, 1 Apr 2009 17:29:24 -0700 (PDT) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id BE10B3A69FA for ; Wed, 1 Apr 2009 17:29:24 -0700 (PDT) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id C8E003DBC46D; Wed, 1 Apr 2009 17:30:25 -0700 (PDT) Message-Id: <3D04F9F4-007F-401C-A91A-5C8C13BC93D3@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Charles Krinke In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-10-479504313 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 1 Apr 2009 17:30:25 -0700 References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 00:29:26 -0000 --Apple-Mail-10-479504313 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Charles... i _think_ we're in radical agreement. Some might read that first sentence as meaning, "you're not fully interoperable unless you can teleport from second life to wonderland to world of warcraft to every other virtual world in existence." But the second sentence seems to imply you're really just talking about "second life-like" systems. If you mean the former... ouch... that's going to be difficult (though i'm sure JW would disagree.) If the latter, then yes, you're right... we're not fully interoperable (in the OGP sense) until you can teleport from a linden controlled server to a OSgrid controlled? federated? server, and then turn around and go back the other way. On Apr 1, 2009, at 5:01 PM, Charles Krinke wrote: > To me, interop implies a full handoff of an avatar from one virtual > world to another. > > I can appreciate OGP offering one half of this in its current form > in a teleport from a SecondLife type grid to an OpenSim type grid. > But, we also need to consider how a citizen of an OpenSim grid can > teleport to a SecondLife grid as well. > > In the case of OpenSim grids, we have a UserServer as opposed to an > AgentDomain, but they offer a similar set of services. > > So, from the MMOX viewpoint, we could perhaps get there from here if > we were to consider the fact that each side of this teleport needs > to be treated in an equal and sovereign manner. > > To me, interop between grids is more of a "border crossing & > customs" paradigm. That is, each grid may have its own border > crossing rules for exit and its own customs rules for entry and each > is sovereign in its own right. That is, there is no overwhelming > AgentDomain that controls all teleports between all grids, but > rather an AgentDomain is a paradigm for one particular grid, or in > the SecondLife case, for a few SecondLife grids all under the > control of one corporate personality. > > Charles Krinke > OpenSim Core Developer > OSGrid Director > > > > > On Wed, Apr 1, 2009 at 3:53 PM, Meadhbh Hamrick (Infinity) > wrote: > > On Apr 1, 2009, at 1:56 PM, Hurliman, John wrote: > > A few days ago I posted an e-mail highlighting my concerns with the > architecture of OGP. I'm not sure if there was an implicit agreement > from the OGP authors or if the e-mail was lost in the flood. I'm > reposting in a new thread because I want to make sure I have a > proper understanding of the architecture. > > > * Indirectly, it highlights that the Agent Domain model does not > have a solution to the problem of accessing worlds with which there is > no trust agreement. People will want to enter arbitrary worlds, and > therefore that restriction is inadequate. > > i would guess the solution would be to have a promiscuous agent > domain that has a "i will trust all worlds" settings. i think this > is a limitation of the implementation, not the architecture. > > * There will be millions of worlds in an Internet-scale > metaverse, > > which makes the concept of interop through trust agreements far too > narrow. Trust loses its meaning entirely when scaled to millions, > becoming mere paperwork or "security theater". > > +1. what's your suggestion? > > > > This is, in my opinion, the fundamental flaw in OGP. Explicit trust > maps (whitelists) work great when IBM wants to define policy to > connect to the Linden Lab grid, but has no meaning and no hope of > scaling when you talk about defining trust for millions of > simulation grids and millions (or at least thousands) of identity > providers. This is the primary reason that Intel and many members of > the OpenSimulator/OpenMetaverse community have not considered OGP as > a strong proposal for virtual world interoperability. If this > understanding is not accurate, it would be helpful if an OGP author > could step in and clear up the confusion. > > John > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > > > -- > Charles Krinke > OpenSim Core Developer > OSGrid Director --Apple-Mail-10-479504313 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Charles... i _think_ we're in = radical agreement. Some might read that first sentence as meaning, = "you're not fully interoperable unless you can teleport from second life = to wonderland to world of warcraft to every other virtual world in = existence." But the second sentence seems to imply you're really just = talking about "second life-like" systems. If you mean the former... = ouch... that's going to be difficult (though i'm sure JW would = disagree.) If the latter, then yes, you're right... we're not fully = interoperable (in the OGP sense) until you can teleport from a linden = controlled server to a OSgrid controlled? federated? server, and then = turn around and go back the other way.

On Apr 1, = 2009, at 5:01 PM, Charles Krinke wrote:

To me, = interop implies a full handoff of an avatar from one virtual world to = another.

I can appreciate OGP offering one half of this in its = current form in a teleport from a SecondLife type grid to an OpenSim = type grid. But, we also need to consider how a citizen of an OpenSim = grid can teleport to a SecondLife grid as well.

In the case of = OpenSim grids, we have a UserServer as opposed to an AgentDomain, but = they offer a similar set of services.

So, from the MMOX = viewpoint, we could perhaps get there from here if we were to consider = the fact that each side of this teleport needs to be treated in an equal = and sovereign manner.

To me, interop between grids is more of a = "border crossing & customs" paradigm. That is, each grid may have = its own border crossing rules for exit and its own customs rules for = entry and each is sovereign in its own right. That is, there is no = overwhelming AgentDomain that controls all teleports between all grids, = but rather an AgentDomain is a paradigm for one particular grid, or in = the SecondLife case, for a few SecondLife grids all under the control of = one corporate personality.

Charles Krinke
OpenSim Core = Developer
OSGrid Director




On Wed, Apr 1, 2009 at 3:53 PM, Meadhbh Hamrick = (Infinity) <infinity@lindenlab.com> wrote:

On Apr 1, 2009, at 1:56 PM, Hurliman, John = wrote:

A few days ago I posted an e-mail highlighting my concerns with = the architecture of OGP. I'm not sure if there was an implicit agreement = from the OGP authors or if the e-mail was lost in the flood. I'm = reposting in a new thread because I want to make sure I have a proper = understanding of the architecture.


*     =   Indirectly, it highlights that the Agent Domain model does = not
have a solution to the problem of accessing worlds with which = there is
no trust agreement.  People will want to enter = arbitrary worlds, and
therefore that restriction is inadequate.
=

i would guess the solution would = be to have a promiscuous agent domain that has a "i will trust all = worlds" settings. i think this is a limitation of the implementation, = not the architecture.

*       There will be = millions of worlds in an Internet-scale metaverse,

= which makes the concept of interop through trust agreements far too
= narrow.  Trust loses its meaning entirely when scaled to = millions,
becoming mere paperwork or "security theater".
=

+1. what's your = suggestion?



This is, in = my opinion, the fundamental flaw in OGP. Explicit trust maps = (whitelists) work great when IBM wants to define policy to connect to = the Linden Lab grid, but has no meaning and no hope of scaling when you = talk about defining trust for millions of simulation grids and millions = (or at least thousands) of identity providers. This is the primary = reason that Intel and many members of the OpenSimulator/OpenMetaverse = community have not considered OGP as a strong proposal for virtual world = interoperability. If this understanding is not accurate, it would be = helpful if an OGP author could step in and clear up the confusion.
=
John
_______________________________________________
mmox = mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox
=

_______________________________________________
= mmox mailing list
mmox@ietf.org
https://www.ietf.org/mailman/listinfo/mmox
=



--
Charles = Krinke
OpenSim Core Developer
OSGrid = Director

= --Apple-Mail-10-479504313-- From jwatte@gmail.com Wed Apr 1 17:41:47 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B90B33A6A28 for ; Wed, 1 Apr 2009 17:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 pPpRrtmsTa3o for ; Wed, 1 Apr 2009 17:41:47 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id 215C63A6A0E for ; Wed, 1 Apr 2009 17:41:47 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so271054rvb.49 for ; Wed, 01 Apr 2009 17:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=IWBxbeLTzNtkyiVnEX8si2ePoMYN0nrZa3xi0+soE4Y=; b=YyP0ifugnrBAjU8nUGCqi3sC2G9nJNPfaOIbboWPaTSIMFNiPOHdn1B4J6UGYy45rX g0Qc/9sUHPFuwz2LcFLwomII6RmUdAjU4jrxM0veMHaAKMZHzaFG7hmp2pjdWMDUiFM9 4p54gxd9U1eJyO8920MEII7vD2l2g4Jhze0l0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=CAZeiBiCdwTNcib/z5mpSIeYZMc+rbjjxQoAgnFYMpqM6Ng+yyTxb8S0XT+vb6NOG4 i9RwLDcDDhAgbwOaJP+3VK9/2aZuSkS9Vm2Mn6COwIWNCf662GEM0p79L7ddJr1pi1+h C0pBul/RbnfFB3F3eZhBDpCsfGnVltnS1B5fU= Received: by 10.141.177.2 with SMTP id e2mr4270839rvp.71.1238632967911; Wed, 01 Apr 2009 17:42:47 -0700 (PDT) Received: from ?10.10.111.233? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id c20sm1362174rvf.0.2009.04.01.17.42.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 01 Apr 2009 17:42:47 -0700 (PDT) Message-ID: <49D40A06.7030708@gmail.com> Date: Wed, 01 Apr 2009 17:42:46 -0700 From: Jon Watte User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Charles Krinke References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 00:41:47 -0000 Charles Krinke wrote: > To me, interop implies a full handoff of an avatar from one virtual > world to another. Is it "virtual worlds interop" if there aren't multiple virtual worlds interoperating involved on an ongoing basis? It sounds like you're describing something like "avatar interop," to me. It may sound pedantic, but I do think it's important to put as unambiguous labels on what we discuss as possible, so that we don't end up making different assumptions without realizing it, and ending up in confusion and discord. Sincerely, jw From charles.krinke@gmail.com Wed Apr 1 17:49:21 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B21573A681A for ; Wed, 1 Apr 2009 17:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] 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 9Q7qKNuJF4GH for ; Wed, 1 Apr 2009 17:49:20 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by core3.amsl.com (Postfix) with ESMTP id 77BB23A6B48 for ; Wed, 1 Apr 2009 17:47:51 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d11so290861and.4 for ; Wed, 01 Apr 2009 17:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=C9nVfAsaFiTmbZaskpsUeCRqucd0hpoyESMHfcrL178=; b=DWHB70dn2/cQaYbAHflcGcuAqGcRowhKbRVIIHgP5vynLwbDXUrFfrRtsALVHjI8oE sJSGS7VMv7hskoz8JgRM3qShydJg+gNnUf5izQcJz0d4rZQXaMoxTm9jBLJB4ZpKSG+o G5aMOKOTeU6htwFMLku/VNqL2wl/58PJgwzaE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Zyz+XrlSbokHFM8+W7jw6yEHPk5BjOzjt+FLMP4cXk0wva+fW/P/GlkyqwGb8LOHDo ro4+GDpSZc3fSVg7yA1GJjV0x2QDv0s3szwvJTkRizP2Ryw1ScOwIR2m83DkdIMxGnJr aCa4W3XSfQrH2OMnjHFN3hVZrWvBntbaQS/p4= MIME-Version: 1.0 Received: by 10.101.71.3 with SMTP id y3mr7800285ank.62.1238633331967; Wed, 01 Apr 2009 17:48:51 -0700 (PDT) In-Reply-To: <3D04F9F4-007F-401C-A91A-5C8C13BC93D3@lindenlab.com> References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <3D04F9F4-007F-401C-A91A-5C8C13BC93D3@lindenlab.com> Date: Wed, 1 Apr 2009 16:48:51 -0800 Message-ID: From: Charles Krinke To: "Meadhbh Hamrick (Infinity)" Content-Type: multipart/alternative; boundary=0016368e1b11c2466a046687cb97 Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 00:49:21 -0000 --0016368e1b11c2466a046687cb97 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Yes, Infinity, I was merely using that as an example. I have the greatest of respect for both you and JHurliman and hope that "whatever" evolves is something both of you can support. I am trying to pick my words very carefully as I dont want to paint you or JHurliman into any corner. But, in any case, as long as interop between virtual worlds is symmetrical, then I can support the notions are they are evolving. Symmetrical in this case meaning that there is *not* an overwhelming, global, metaversal server somewhere that *everyone* needs an account on in order to accomplish interop. Charles Krinke OpenSim Core Developer OSGrid Director On Wed, Apr 1, 2009 at 4:30 PM, Meadhbh Hamrick (Infinity) < infinity@lindenlab.com> wrote: > Charles... i _think_ we're in radical agreement. Some might read that first > sentence as meaning, "you're not fully interoperable unless you can teleport > from second life to wonderland to world of warcraft to every other virtual > world in existence." But the second sentence seems to imply you're really > just talking about "second life-like" systems. If you mean the former... > ouch... that's going to be difficult (though i'm sure JW would disagree.) If > the latter, then yes, you're right... we're not fully interoperable (in the > OGP sense) until you can teleport from a linden controlled server to a > OSgrid controlled? federated? server, and then turn around and go back the > other way. > > On Apr 1, 2009, at 5:01 PM, Charles Krinke wrote: > > To me, interop implies a full handoff of an avatar from one virtual world > to another. > > I can appreciate OGP offering one half of this in its current form in a > teleport from a SecondLife type grid to an OpenSim type grid. But, we also > need to consider how a citizen of an OpenSim grid can teleport to a > SecondLife grid as well. > > In the case of OpenSim grids, we have a UserServer as opposed to an > AgentDomain, but they offer a similar set of services. > > So, from the MMOX viewpoint, we could perhaps get there from here if we > were to consider the fact that each side of this teleport needs to be > treated in an equal and sovereign manner. > > To me, interop between grids is more of a "border crossing & customs" > paradigm. That is, each grid may have its own border crossing rules for exit > and its own customs rules for entry and each is sovereign in its own right. > That is, there is no overwhelming AgentDomain that controls all teleports > between all grids, but rather an AgentDomain is a paradigm for one > particular grid, or in the SecondLife case, for a few SecondLife grids all > under the control of one corporate personality. > > Charles Krinke > OpenSim Core Developer > OSGrid Director > > > > > On Wed, Apr 1, 2009 at 3:53 PM, Meadhbh Hamrick (Infinity) < > infinity@lindenlab.com> wrote: > >> >> On Apr 1, 2009, at 1:56 PM, Hurliman, John wrote: >> >> A few days ago I posted an e-mail highlighting my concerns with the >>> architecture of OGP. I'm not sure if there was an implicit agreement from >>> the OGP authors or if the e-mail was lost in the flood. I'm reposting in a >>> new thread because I want to make sure I have a proper understanding of the >>> architecture. >>> >>> >>> * Indirectly, it highlights that the Agent Domain model does not >>>> have a solution to the problem of accessing worlds with which there is >>>> no trust agreement. People will want to enter arbitrary worlds, and >>>> therefore that restriction is inadequate. >>>> >>> >> i would guess the solution would be to have a promiscuous agent domain >> that has a "i will trust all worlds" settings. i think this is a limitation >> of the implementation, not the architecture. >> >> * There will be millions of worlds in an Internet-scale metaverse, >>>> which makes the concept of interop through trust agreements far too >>>> narrow. Trust loses its meaning entirely when scaled to millions, >>>> becoming mere paperwork or "security theater". >>>> >>> >> +1. what's your suggestion? >> >> >> >>> This is, in my opinion, the fundamental flaw in OGP. Explicit trust maps >>> (whitelists) work great when IBM wants to define policy to connect to the >>> Linden Lab grid, but has no meaning and no hope of scaling when you talk >>> about defining trust for millions of simulation grids and millions (or at >>> least thousands) of identity providers. This is the primary reason that >>> Intel and many members of the OpenSimulator/OpenMetaverse community have not >>> considered OGP as a strong proposal for virtual world interoperability. If >>> this understanding is not accurate, it would be helpful if an OGP author >>> could step in and clear up the confusion. >>> >>> John >>> _______________________________________________ >>> mmox mailing list >>> mmox@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmox >>> >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> > > > > -- > Charles Krinke > OpenSim Core Developer > OSGrid Director > > > -- Charles Krinke OpenSim Core Developer OSGrid Director --0016368e1b11c2466a046687cb97 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, Infinity, I was merely using that as an example.

I have the gre= atest of respect for both you and JHurliman and hope that "whatever&qu= ot; evolves is something both of you can support. I am trying to pick my wo= rds very carefully as I dont want to paint you or JHurliman into any corner= .

But, in any case, as long as interop between virtual worlds is symmetri= cal, then I can support the notions are they are evolving. Symmetrical in t= his case meaning that there is *not* an overwhelming, global, metaversal se= rver somewhere that *everyone* needs an account on in order to accomplish i= nterop.

Charles Krinke
OpenSim Core Developer
OSGrid Director


=
On Wed, Apr 1, 2009 at 4:30 PM, Meadhbh Hamrick = (Infinity) <= infinity@lindenlab.com> wrote:
C= harles... i _think_ we're in radical agreement. Some might read that fi= rst sentence as meaning, "you're not fully interoperable unless yo= u can teleport from second life to wonderland to world of warcraft to every= other virtual world in existence." But the second sentence seems to i= mply you're really just talking about "second life-like" syst= ems. If you mean the former... ouch... that's going to be difficult (th= ough i'm sure JW would disagree.) If the latter, then yes, you're r= ight... we're not fully interoperable (in the OGP sense) until you can = teleport from a linden controlled server to a OSgrid controlled? federated?= server, and then turn around and go back the other way.

On Apr 1, 2009, at 5:0= 1 PM, Charles Krinke wrote:

To me, inter= op implies a full handoff of an avatar from one virtual world to another. <= br>
I can appreciate OGP offering one half of this in its current form in a= teleport from a SecondLife type grid to an OpenSim type grid. But, we also= need to consider how a citizen of an OpenSim grid can teleport to a Second= Life grid as well.

In the case of OpenSim grids, we have a UserServer as opposed to an Ag= entDomain, but they offer a similar set of services.

So, from the MM= OX viewpoint, we could perhaps get there from here if we were to consider t= he fact that each side of this teleport needs to be treated in an equal and= sovereign manner.

To me, interop between grids is more of a "border crossing & = customs" paradigm. That is, each grid may have its own border crossing= rules for exit and its own customs rules for entry and each is sovereign i= n its own right. That is, there is no overwhelming AgentDomain that control= s all teleports between all grids, but rather an AgentDomain is a paradigm = for one particular grid, or in the SecondLife case, for a few SecondLife gr= ids all under the control of one corporate personality.

Charles Krinke
OpenSim Core Developer
OSGrid Director



On Wed, Apr 1, 2009 at 3:53 PM, Meadhbh= Hamrick (Infinity) <infinity@lindenlab.com> wrote:

On Apr= 1, 2009, at 1:56 PM, Hurliman, John wrote:

A few days ago I posted an e-mail highlighting my concerns with the archit= ecture of OGP. I'm not sure if there was an implicit agreement from the= OGP authors or if the e-mail was lost in the flood. I'm reposting in a= new thread because I want to make sure I have a proper understanding of th= e architecture.


* =C2= =A0 =C2=A0 =C2=A0 Indirectly, it highlights that the Agent Domain model doe= s not
have a solution to the problem of accessing worlds with which the= re is
no trust agreement. =C2=A0People will want to enter arbitrary worlds, and<= br> therefore that restriction is inadequate.

i would guess the solution would be to have a promiscuous agen= t domain that has a "i will trust all worlds" settings. i think t= his is a limitation of the implementation, not the architecture.

* =C2=A0 =C2=A0 =C2=A0 There will be millions of worlds in an Internet-sca= le metaverse,

which makes the concept of interop through trust agr= eements far too
narrow. =C2=A0Trust loses its meaning entirely when sca= led to millions,
becoming mere paperwork or "security theater".

+1. what's your suggestion?



This is, in my opinion, the fundamental flaw in OGP. Explicit trust m= aps (whitelists) work great when IBM wants to define policy to connect to t= he Linden Lab grid, but has no meaning and no hope of scaling when you talk= about defining trust for millions of simulation grids and millions (or at = least thousands) of identity providers. This is the primary reason that Int= el and many members of the OpenSimulator/OpenMetaverse community have not c= onsidered OGP as a strong proposal for virtual world interoperability. If t= his understanding is not accurate, it would be helpful if an OGP author cou= ld step in and clear up the confusion.

John
_______________________________________________
mmox mai= ling list
mmox@ietf.= org
https://www.ietf.org/mailman/listinfo/mmox

_______________________________________________
mmo= x mailing list
mmox@= ietf.org
https://www.ietf.org/mailman/listinfo/mmox



--
Charles Kr= inke
OpenSim Core Developer
OSGrid Director


--
Charles Krinke
OpenSim Core Developer
OSGrid Director
--0016368e1b11c2466a046687cb97-- From lenglish5@cox.net Wed Apr 1 18:02:55 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CF153A68BA for ; Wed, 1 Apr 2009 18:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.438 X-Spam-Level: X-Spam-Status: No, score=-0.438 tagged_above=-999 required=5 tests=[AWL=1.031, 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 Sjo1bSCEjHcr for ; Wed, 1 Apr 2009 18:02:54 -0700 (PDT) Received: from fed1rmmtao103.cox.net (fed1rmmtao103.cox.net [68.230.241.43]) by core3.amsl.com (Postfix) with ESMTP id 3A01C3A6821 for ; Wed, 1 Apr 2009 18:02:54 -0700 (PDT) Received: from fed1rmimpo02.cox.net ([70.169.32.72]) by fed1rmmtao103.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090402010351.EGRV4363.fed1rmmtao103.cox.net@fed1rmimpo02.cox.net>; Wed, 1 Apr 2009 21:03:51 -0400 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo02.cox.net with bizsmtp id aR3r1b0024N6T0Q04R3rX4; Wed, 01 Apr 2009 21:03:51 -0400 X-Authority-Analysis: v=1.0 c=1 a=Wajolswj7cQA:10 a=iXggwkVfAAAA:8 a=NiGd_wc_Kv_4tqS2ARkA:9 a=SYVMIqFBJ5Xwz2_RZ4sA:7 a=Gghf4DG673CI-Y7EdOOt6tp5Zg4A:4 a=C35D7iIojSgA:10 a=x6U5xrJgyBEA:10 a=0N1Iu_55o71-rJdb:21 a=g-CuPFemVdVthyqf:21 X-CM-Score: 0.00 Message-ID: <49D40EF6.3050609@cox.net> Date: Wed, 01 Apr 2009 18:03:50 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Charles Krinke References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <3D04F9F4-007F-401C-A91A-5C8C13BC93D3@lindenlab.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 01:02:55 -0000 Charles Krinke wrote: > Yes, Infinity, I was merely using that as an example. > > I have the greatest of respect for both you and JHurliman and hope > that "whatever" evolves is something both of you can support. I am > trying to pick my words very carefully as I dont want to paint you or > JHurliman into any corner. > > But, in any case, as long as interop between virtual worlds is > symmetrical, then I can support the notions are they are evolving. > Symmetrical in this case meaning that there is *not* an overwhelming, > global, metaversal server somewhere that *everyone* needs an account > on in order to accomplish interop. > > Charles Krinke > OpenSim Core Developer > OSGrid Director > > > On Wed, Apr 1, 2009 at 4:30 PM, Meadhbh Hamrick (Infinity) > > wrote: > > Charles... i _think_ we're in radical agreement. Some might read > that first sentence as meaning, "you're not fully interoperable > unless you can teleport from second life to wonderland to world of > warcraft to every other virtual world in existence." But the > second sentence seems to imply you're really just talking about > "second life-like" systems. If you mean the former... ouch... > that's going to be difficult (though i'm sure JW would disagree.) > If the latter, then yes, you're right... we're not fully > interoperable (in the OGP sense) until you can teleport from a > linden controlled server to a OSgrid controlled? federated? > server, and then turn around and go back the other way. > > On Apr 1, 2009, at 5:01 PM, Charles Krinke wrote: > >> To me, interop implies a full handoff of an avatar from one >> virtual world to another. >> >> I can appreciate OGP offering one half of this in its current >> form in a teleport from a SecondLife type grid to an OpenSim type >> grid. But, we also need to consider how a citizen of an OpenSim >> grid can teleport to a SecondLife grid as well. >> >> In the case of OpenSim grids, we have a UserServer as opposed to >> an AgentDomain, but they offer a similar set of services. >> >> So, from the MMOX viewpoint, we could perhaps get there from here >> if we were to consider the fact that each side of this teleport >> needs to be treated in an equal and sovereign manner. >> >> To me, interop between grids is more of a "border crossing & >> customs" paradigm. That is, each grid may have its own border >> crossing rules for exit and its own customs rules for entry and >> each is sovereign in its own right. That is, there is no >> overwhelming AgentDomain that controls all teleports between all >> grids, but rather an AgentDomain is a paradigm for one particular >> grid, or in the SecondLife case, for a few SecondLife grids all >> under the control of one corporate personality. > I had always assumed that agent domains were trusted to a certain extent by all grids/regions that allow their avies in but the converse was not true. This would be analogous to the border guard granting a temp/tourist visa to the "non-authorized by recognized Agent Domain avies," while providing a more formal passport to those that are. Euro-pass vs work-visa vs passport vs citizenship papers or somesuch. Lawson From lenglish5@cox.net Wed Apr 1 18:04:52 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3DCB3A687D for ; Wed, 1 Apr 2009 18:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.843 X-Spam-Level: X-Spam-Status: No, score=0.843 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_50=0.001, 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 f9KqwaRb+Pip for ; Wed, 1 Apr 2009 18:04:51 -0700 (PDT) Received: from fed1rmmtao107.cox.net (fed1rmmtao107.cox.net [68.230.241.39]) by core3.amsl.com (Postfix) with ESMTP id 1560C3A67CC for ; Wed, 1 Apr 2009 18:04:51 -0700 (PDT) Received: from fed1rmimpo01.cox.net ([70.169.32.71]) by fed1rmmtao107.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090402010552.DDFK10385.fed1rmmtao107.cox.net@fed1rmimpo01.cox.net> for ; Wed, 1 Apr 2009 21:05:52 -0400 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo01.cox.net with bizsmtp id aR5r1b00C4N6T0Q03R5r0Y; Wed, 01 Apr 2009 21:05:51 -0400 X-Authority-Analysis: v=1.0 c=1 a=M0ekKXdxTI4A:10 a=1IxE_5CaAAAA:8 a=ZOc32ufD4HfKv90D4fAA:9 a=zZUt1m0mZKS4k9mBYe7zY8VoshYA:4 a=-5uJZQ4sNmgA:10 X-CM-Score: 0.00 Message-ID: <49D40F6F.9040103@cox.net> Date: Wed, 01 Apr 2009 18:05:51 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "mmox@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mmox] heads up... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "mmox@ietf.org" List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 01:04:52 -0000 DOn't know if any mmox folk are involved in this or not... http://mediagrid.org/summit/2009_London_Summit_program.html#PANEL_FUTURE_OF_VIRTUAL_WORLDS Lawson From infinity@lindenlab.com Wed Apr 1 18:49:31 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0315E3A6A61 for ; Wed, 1 Apr 2009 18:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.526 X-Spam-Level: X-Spam-Status: No, score=-3.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 SRgDs7d61lRx for ; Wed, 1 Apr 2009 18:49:30 -0700 (PDT) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 0B9B23A685D for ; Wed, 1 Apr 2009 18:49:30 -0700 (PDT) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 114E13DBC464; Wed, 1 Apr 2009 18:50:31 -0700 (PDT) Message-Id: <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Jon Watte In-Reply-To: <49D40A06.7030708@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 1 Apr 2009 18:50:30 -0700 References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <49D40A06.7030708@gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 01:49:31 -0000 Okay... if we want to get pedantic, then let's get pedantic. * 47 CFR 51.3 defines interoperability as "the ability of two or = more =20 facilities, or networks, to be connected, to exchange information, and =20= to use the information that has been exchanged." * 17 USCS =A7 1201 describes interoperability as "means the = ability of =20 computer programs to exchange information, and of such programs =20 mutually to use the information which has been exchanged." * 44 USCS =A7 3601 describes interoperability as "the ability of = =20 different operating and software systems, applications, and services =20 to communicate and exchange data in an accurate, effective, and =20 consistent manner." * The IEEE has used "the ability of two or more systems or = components =20 to exchange information and to use the information that has been =20 exchanged." as the definition of the term. I would suggest that we all might be using the term incorrectly as the =20= definitions above imply an exchange of information; that is, =20 information flows between two facilities, networks, computer programs, =20= operating systems, applications, services, systems or components. Perhaps it is more appropriate to say: * "Second Life (as a service) has demonstrated interoperability = with =20 an instance of OpenSim using a version of the OGP protocol." or * "sim3078.aditi.lindenlab.com has demonstrated interoperability = with =20 ec2-XXX-XXX-XXX-XXX.compute-1.amazonaws.com using a version of the OGP =20= protocol." or * "Second Life server version 1.22 (as a software system) has =20= demonstrated interoperability with a version of OpenSim." But I would defend our previous usage of the term to describe OGP as =20 an "interoperability protocol" because, in fact, there are software =20 systems (Second Life and OpenSim) which use it to exchange information =20= which is used by either system. I believe the term you're looking for, given your usage is =20 "universality." And no, OGP does not provide universality. OGP does =20 not allow WoW to talk with Star Wars Galaxies or There.Com or a =20 Forterra simulation. It also doesn't solve world hunger or global =20 warming. But then again, OGP was not intended to provide that kind of =20= universality (or to solve world hunger.) And I would suggest that =20 neither LESS nor DIS nor HLA were designed for universality either. I =20= further believe that universality is not a feature of a protocol, but =20= of markets, products and possibly networks. -cheers -meadhbh On Apr 1, 2009, at 5:42 PM, Jon Watte wrote: > Charles Krinke wrote: >> To me, interop implies a full handoff of an avatar from one virtual =20= >> world to another. > > Is it "virtual worlds interop" if there aren't multiple virtual =20 > worlds interoperating involved on an ongoing basis? > It sounds like you're describing something like "avatar interop," to =20= > me. > > It may sound pedantic, but I do think it's important to put as =20 > unambiguous labels on what we discuss as possible, so that we don't =20= > end up making different assumptions without realizing it, and ending =20= > up in confusion and discord. > > Sincerely, > > jw > From jwatte@gmail.com Wed Apr 1 19:55:29 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BFBD3A6957 for ; Wed, 1 Apr 2009 19:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 kmTZNtbS7pVp for ; Wed, 1 Apr 2009 19:55:28 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by core3.amsl.com (Postfix) with ESMTP id 923AF3A67F2 for ; Wed, 1 Apr 2009 19:55:28 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id l35so178139waf.5 for ; Wed, 01 Apr 2009 19:56:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=B81VS/53rMpHeo81jQE3FIQQDVJerVG60PQ8+cbgON0=; b=Mtn8wcs2IBJg9gAMVJ8u4yu3HMTLfUGi3v6kDwJojz9CDgAWA6YPcqCczjjYc8CjkT quP3Ue2Rb59n+VI19iEPV8IIVd/Vp/jYfmeuCCC2Krx6oHAsARcAz0P/W5jupPfoT/w6 ZZfCD4iQ49ClXlqYzmL87j3nNMGiZY4Uy+QXQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=mSpURySB2pT8VNVZJ6Avp5Kxb9XcMbiFr7VDchR13/z1J/ah5dccFKDLu3TTUFGfLj AsxwEjl5x3JQCCTKGKa+B5jxJUXyJOl7cbzEhiJ7kNOhkhidCRDfCnvsooe1HBmELR62 R42NLFJkgx5zHLMtxBx+Iv07bdG235pIDSyL0= Received: by 10.114.181.6 with SMTP id d6mr5639522waf.8.1238640989620; Wed, 01 Apr 2009 19:56:29 -0700 (PDT) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id m31sm625419wag.29.2009.04.01.19.56.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 01 Apr 2009 19:56:29 -0700 (PDT) Message-ID: <49D4295C.2020502@gmail.com> Date: Wed, 01 Apr 2009 19:56:28 -0700 From: Jon Watte User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <49D40A06.7030708@gmail.com> <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> In-Reply-To: <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 02:55:29 -0000 Meadhbh Hamrick (Infinity) wrote: > I believe the term you're looking for, given your usage is > "universality." And no, OGP does not provide universality. OGP >> >> It may sound pedantic, but I do think it's important to put as >> unambiguous labels on what we discuss as possible, so that we don't >> end up making different assumptions without realizing it, and ending >> up in confusion and discord. I'm sorry: I think you misunderstood what I was saying and took it the wrong way. The word "interop" is clearly correct, and I am not arguing against that. My argument is against labeling anything and everything as "virtual world interop." As we've seen, it's a term that is so broad as to be almost meaningless. I'm merely arguing for specificity. The proposal is to be more detailed about what kind of interop we're talking about in any particular case. For example, there might be VoIP interop, or avatar interop, or authentication interop, or simulation interop, or service brokerage interop, or online status interop, or text chat interop. Those are all forms of interop necessary to accomplish "full virtual world interop." The confusion arises when someone talks about "virtual worlds interop" but is actually only discussing one piece. In my opinion, it would be more accurate, and help everybody, to clearly specify the piece you're talking about. Sincerely, jw From infinity@lindenlab.com Wed Apr 1 20:00:10 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E44213A6957 for ; Wed, 1 Apr 2009 20:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.527 X-Spam-Level: X-Spam-Status: No, score=-3.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 kQM-j63xjk+F for ; Wed, 1 Apr 2009 20:00:10 -0700 (PDT) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 3044F3A6821 for ; Wed, 1 Apr 2009 20:00:10 -0700 (PDT) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 59AB03DBC446; Wed, 1 Apr 2009 20:01:11 -0700 (PDT) Message-Id: <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Jon Watte In-Reply-To: <49D4295C.2020502@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 1 Apr 2009 20:01:11 -0700 References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <49D40A06.7030708@gmail.com> <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> <49D4295C.2020502@gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 03:00:11 -0000 so maybe we might say "virtual world avatar interop" or "virtual world event stream interop"? but not say "virtual world interop" 'cause it's too vague? On Apr 1, 2009, at 7:56 PM, Jon Watte wrote: > Meadhbh Hamrick (Infinity) wrote: >> I believe the term you're looking for, given your usage is >> "universality." And no, OGP does not provide universality. OGP > >>> >>> It may sound pedantic, but I do think it's important to put as >>> unambiguous labels on what we discuss as possible, so that we >>> don't end up making different assumptions without realizing it, >>> and ending up in confusion and discord. > > I'm sorry: I think you misunderstood what I was saying and took it > the wrong way. The word "interop" is clearly correct, and I am not > arguing against that. My argument is against labeling anything and > everything as "virtual world interop." As we've seen, it's a term > that is so broad as to be almost meaningless. I'm merely arguing for > specificity. > > The proposal is to be more detailed about what kind of interop we're > talking about in any particular case. For example, there might be > VoIP interop, or avatar interop, or authentication interop, or > simulation interop, or service brokerage interop, or online status > interop, or text chat interop. Those are all forms of interop > necessary to accomplish "full virtual world interop." The confusion > arises when someone talks about "virtual worlds interop" but is > actually only discussing one piece. In my opinion, it would be more > accurate, and help everybody, to clearly specify the piece you're > talking about. > > Sincerely, > > jw > From charles.krinke@gmail.com Wed Apr 1 20:27:27 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 819913A6957 for ; Wed, 1 Apr 2009 20:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.308 X-Spam-Level: X-Spam-Status: No, score=-2.308 tagged_above=-999 required=5 tests=[AWL=0.290, 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 pXd4hUxQ-iL1 for ; Wed, 1 Apr 2009 20:27:26 -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 863C53A6838 for ; Wed, 1 Apr 2009 20:27:26 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so467405ywh.49 for ; Wed, 01 Apr 2009 20:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Sp3VBLpsbnR4P6XiQTxLAy4WSiqQ2H9XMKXtHP9R+yI=; b=p/0plj0I+6N7z6i1e985QA4sA2cK4BUrFC5ZwwIr1CLF07dOgL/skvDX6uaekt46ZH XMq15D/H/M2t5+iYddn+he1Q3JqSOerFobjwzDF93jBwEpilrDUM7TDk/fd++3fGOjj7 J4QYXz4xLwd1/5dSYGcDp9YmQO8yOEQXZUKss= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=d1hrm+h0hgsYQ+tAHxzRJXkPF4eqPzSvlReGaWnSKfVNN4YyaLlu6noBYnhFRZr/mZ jGUycySlugEhNjfQejBqq8fpRifzwSDLiLX5sx0UOdPxRXnT21f4BUSMKLMPr5uqBlW9 aiJO6X/LDTGAGtEA2INtsSewfBq7WU8XGfzlY= MIME-Version: 1.0 Received: by 10.100.239.11 with SMTP id m11mr8009400anh.83.1238642907250; Wed, 01 Apr 2009 20:28:27 -0700 (PDT) In-Reply-To: <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <49D40A06.7030708@gmail.com> <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> <49D4295C.2020502@gmail.com> <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> Date: Thu, 2 Apr 2009 03:28:27 +0000 Message-ID: From: Charles Krinke To: "Meadhbh Hamrick (Infinity)" Content-Type: multipart/alternative; boundary=0016368e24fc7d807d04668a06d9 Cc: "mmox@ietf.org" , Jon Watte Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 03:27:27 -0000 --0016368e24fc7d807d04668a06d9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit At this point, I would really be interested in hearing what JHurliman has to say and suggest. Getting JHurliman to where he feels more comfortable with the direction of the interop discussion is something important to me and others. -- Charles Krinke OpenSim Core Developer OSGrid Director --0016368e24fc7d807d04668a06d9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit At this point, I would really be interested in hearing what JHurliman has to say and suggest. Getting JHurliman to where he feels more comfortable with the direction of the interop discussion is something important to me and others.
--
Charles Krinke
OpenSim Core Developer
OSGrid Director
--0016368e24fc7d807d04668a06d9-- From morgaine.dinova@googlemail.com Wed Apr 1 22:25:37 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBC243A6AA3 for ; Wed, 1 Apr 2009 22:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.315 X-Spam-Level: X-Spam-Status: No, score=-1.315 tagged_above=-999 required=5 tests=[AWL=-0.339, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_BACKHAIR_44=1] 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 0NFN6WjPVESw for ; Wed, 1 Apr 2009 22:25:36 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 5AC7E3A682F for ; Wed, 1 Apr 2009 22:25:36 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so77752eyf.31 for ; Wed, 01 Apr 2009 22:26: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=4/xhzmdqvtkIjEnlP45kM72VnZzDgBM0K4Er/78DTiM=; b=NuvFdbm1V5SkJFMGZHqe2aRwlQWPX11NVB+FlufaS/jDjczJGkHeJAQcm73RLOD9vY dfUDRcm8NBUOl/8x/b5N/Fi4EeYmHtOKaWxJk3znDOY6sSX65FN+R5wxpWw2wcENO0xB hsG8Bfor0DQsHwHBaxDdmxVfY+R883AQ2o+l8= 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=BE3oq1YRfDqsePfAWiYGBOYlk8C5RY8mGV/Dl+UmQhU0uhkralyw/LFb0ytstpyxtO STajem1ElmJv+ExFW2KZ2Kbvs2dWP7S/BwRdI962hNvLdZFg6Dm3ty1Yd8jbCIuPjDcs Yv62sY6HnMCdgxzHERPuRUgPwk4Xsn6OTg1ug= MIME-Version: 1.0 Received: by 10.216.29.201 with SMTP id i51mr2871828wea.214.1238649996463; Wed, 01 Apr 2009 22:26:36 -0700 (PDT) In-Reply-To: References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <49D40A06.7030708@gmail.com> <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> <49D4295C.2020502@gmail.com> <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> Date: Thu, 2 Apr 2009 06:26:36 +0100 Message-ID: From: Morgaine To: Charles Krinke Content-Type: multipart/alternative; boundary=0016368e2f4f0a509104668bad38 Cc: Jon Watte , "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 05:25:37 -0000 --0016368e2f4f0a509104668bad38 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit As I see it, a good part of the reason for the tangle surrounding the word "interop" seems to be that people are focusing on the *mechanisms* that they believe it requires, and these mechanisms are often architecture-dependent so there isn't much immediate agreement. In contrast, if we look at *user expectations* then the situation becomes much simpler and clearer. Users already know what a single virtual world looks like, and they also know what it means to move or teleport between different regions of that single world. So, when they hear that other worlds are out there and that we are offering *interop* between old worlds and new, they know exactly what to expect: *the same as before, but extended to regions in the new worlds as well*. For our purposes in this protocol group, the above user expectation is actually very easy to turn into a definition that has useful structural properties, which I've stated before. Full VW interop is, in essence: *To create a mashup for the user, in which the user's avatar and objects from one world are perceived to be in a new world, and are also perceived by others in that new world. * Despite this interop goal being expressed in pure user terms, it's remarkably structural too: it tells us immediately that for successful interop, we need to gather together data from many different sources (either worlds or services employed by those worlds), otherwise that mashup will not occur and user expectations will be dashed. I think it's a good sign that everyone who has commented on this user view of interop before has agreed with it --- it probably means that we actually have the same goal in mind, but just seem to be approaching it from different angles. Lisa also provided a persona-oriented use casethat underlined the social dimension of interop, and added one important element to the picture: *continuity* in social elements, such as names, friends, places, and easy travel or access, as well as visual (or at least perceptual) continuity. The more seamless we can make the user experience of interop, the higher will be our degree of success. I think we actually know what *interop* is, from a user perspective. If we start from there, it might help us to converge on a common technical view as well. Morgaine. --0016368e2f4f0a509104668bad38 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As I see it, a good part of the reason for the tangle surrounding the word = "interop" seems to be that people are focusing on the mechanis= ms that they believe it requires, and these mechanisms are often archit= ecture-dependent so there isn't much immediate agreement.

In contrast, if we look at user expectations then the situation = becomes much simpler and clearer.

Users already know what a single v= irtual world looks like, and they also know what it means to move or telepo= rt between different regions of that single world.=A0 So, when they hear th= at other worlds are out there and that we are offering interop betwe= en old worlds and new, they know exactly what to expect:=A0 the same = as before, but extended to regions in the new worlds as well.

For our purposes in this protocol group, the above user expectation is = actually very easy to turn into a definition that has useful structural pro= perties, which I've stated before.=A0 Full VW interop is, in essence:

To create a mashup for the use= r, in which the user's avatar and objects from one world are perceived = to be in a new world, and are also perceived by others in that new world.


Despite this interop goal being expressed in pure user te= rms, it's remarkably structural too:=A0 it tells us immediately that fo= r successful interop, we need to gather together data from many different s= ources (either worlds or services employed by those worlds), otherwise that= mashup will not occur and user expectations will be dashed.

I think it's a good sign that everyone who has commented on this us= er view of interop before has agreed with it --- it probably means that we = actually have the same goal in mind, but just seem to be approaching it fro= m different angles.

Lisa also provided a persona-oriented use case that underlined the= social dimension of interop, and added one important element to the pictur= e:=A0 continuity in social elements, such as names, friends, places,= and easy travel or access, as well as visual (or at least perceptual) cont= inuity.=A0 The more seamless we can make the user experience of interop, th= e higher will be our degree of success.

I think we actually know what interop is, from a user perspectiv= e.=A0 If we start from there, it might help us to converge on a common tech= nical view as well.

Morgaine.

--0016368e2f4f0a509104668bad38-- From gigstaggart@gmail.com Wed Apr 1 23:59:27 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1C673A6874 for ; Wed, 1 Apr 2009 23:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] 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 awqLz1BmY-qi for ; Wed, 1 Apr 2009 23:59:27 -0700 (PDT) Received: from QMTA01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by core3.amsl.com (Postfix) with ESMTP id DFF6C3A6867 for ; Wed, 1 Apr 2009 23:59:26 -0700 (PDT) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA01.westchester.pa.mail.comcast.net with comcast id aWzX1b00316LCl051X0Uwg; Thu, 02 Apr 2009 07:00:28 +0000 Received: from [172.16.2.102] ([71.63.105.172]) by OMTA06.westchester.pa.mail.comcast.net with comcast id aX0U1b0073jBa3r3SX0Uoo; Thu, 02 Apr 2009 07:00:28 +0000 Message-ID: <49D4628B.9050207@gmail.com> Date: Thu, 02 Apr 2009 03:00:27 -0400 From: Jason Giglio User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms060209040703010008000707" Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 06:59:28 -0000 This is a cryptographically signed message in MIME format. --------------ms060209040703010008000707 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Meadhbh Hamrick (Infinity) wrote: >>> * There will be millions of worlds in an Internet-scale metaverse, >>> which makes the concept of interop through trust agreements far too >>> narrow. Trust loses its meaning entirely when scaled to millions, >>> becoming mere paperwork or "security theater". > > +1. what's your suggestion? My suggestion is that it's not appropriate to talk about client identity, trust, or authentication as a service to be provided in a centralized manner. The rest of the Internet gets along just fine without it. Sure I can get a CA to sign something that says I am who I am, but no one much cares; the rest of the net has routed around the problem of client identification. I'm not sure why we would need to tackle something so fundamentally difficult here, when it's not really necessary. -Jason --------------ms060209040703010008000707 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJEzCC AuQwggJNoAMCAQICEDy/eM9qH1V7jG7yA4Dmc9swDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDQyMzE5Mjg0NVoX DTA5MDQyMzE5Mjg0NVowRzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEkMCIG CSqGSIb3DQEJARYVZ2lnc3RhZ2dhcnRAZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAusivzNdRqv4A0IGuFvrQ5hBGaeYE1sNkOFhP3nmc4Um0+ca+mj3c8g35 1NI1MkpU0vrnJ11uzu8m6Sr9g3C5eFdu5vf/iapf1ZxlsO5vlbyLqUUPgL0ViNkvYHK0YP3y 6rCJds7h3eeeEhTPG5mQbI24M7DvCHMUXZ2aXGlVLF+KAJf5Rb7gnYzpnIH9Si3BrXmhkNtn 09d9TQQsCD62jm2mmWC5VRhB3qJ1nnNr3qDw2ARpgXEtOSIbIE60yENc51pPE/mKezAFmVla XCgBNqqIOD7M+PFhEBLX8TKGzydxYZ22v0jorS2qrWMXnFOawfVrOGmR6JrWLqYy34AR3QID AQABozIwMDAgBgNVHREEGTAXgRVnaWdzdGFnZ2FydEBnbWFpbC5jb20wDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQUFAAOBgQAQG6K6BHPE8oaMaDvuIb0443OhNl2DJ3de9/D8CI39AVC8 eA4kU/8+/vDO8Q1ZN3EuKAlsav0KbG7E6rZuwdnmvnVgcoSsbmrQDd33Uy8/iFUD2PC2J4tC DNtGVDYfYxYR3VPCzvNcZdBbQoSv0dL59u8orxvFHi8XY/ilhUwInzCCAuQwggJNoAMCAQIC EDy/eM9qH1V7jG7yA4Dmc9swDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkExJTAjBgNV BAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJz b25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDQyMzE5Mjg0NVoXDTA5MDQyMzE5Mjg0 NVowRzEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEkMCIGCSqGSIb3DQEJARYV Z2lnc3RhZ2dhcnRAZ21haWwuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA usivzNdRqv4A0IGuFvrQ5hBGaeYE1sNkOFhP3nmc4Um0+ca+mj3c8g351NI1MkpU0vrnJ11u zu8m6Sr9g3C5eFdu5vf/iapf1ZxlsO5vlbyLqUUPgL0ViNkvYHK0YP3y6rCJds7h3eeeEhTP G5mQbI24M7DvCHMUXZ2aXGlVLF+KAJf5Rb7gnYzpnIH9Si3BrXmhkNtn09d9TQQsCD62jm2m mWC5VRhB3qJ1nnNr3qDw2ARpgXEtOSIbIE60yENc51pPE/mKezAFmVlaXCgBNqqIOD7M+PFh EBLX8TKGzydxYZ22v0jorS2qrWMXnFOawfVrOGmR6JrWLqYy34AR3QIDAQABozIwMDAgBgNV HREEGTAXgRVnaWdzdGFnZ2FydEBnbWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0B AQUFAAOBgQAQG6K6BHPE8oaMaDvuIb0443OhNl2DJ3de9/D8CI39AVC8eA4kU/8+/vDO8Q1Z N3EuKAlsav0KbG7E6rZuwdnmvnVgcoSsbmrQDd33Uy8/iFUD2PC2J4tCDNtGVDYfYxYR3VPC zvNcZdBbQoSv0dL59u8orxvFHi8XY/ilhUwInzCCAz8wggKooAMCAQICAQ0wDQYJKoZIhvcN AQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT CUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNv bTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYD VQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVy c29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkV cI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUq VIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMG A1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZy ZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJp dmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIX oUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydx VyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8x ggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWlu ZyBDQQIQPL94z2ofVXuMbvIDgOZz2zAJBgUrDgMCGgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA0MDIwNzAwMjdaMCMGCSqGSIb3DQEJBDEW BBQQDAYZcF6tNXTUCOlf9bhsVg0TaTBfBgkqhkiG9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhA8v3jPah9Ve4xu8gOA5nPbMIGHBgsqhkiG9w0BCRAC CzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkp IEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhA8 v3jPah9Ve4xu8gOA5nPbMA0GCSqGSIb3DQEBAQUABIIBADt1fqGgFOhByIVpso6Xn8duqsXk yXXuL1WiUtOoJ7lnmaYDzLBpNbrtVUpz8u1XnnZ93AkcGYIzbSXaOBbryVQL+cEXweL3X7eF 2/tpkJeF2XLfSrWBRd5gjlzQqDiRDgL9x/67hVNKCCfX1QuXJU72e3f1CU9DQrfLyEbF1haL 5HlhQkHA0FgUedZSGi9PWK0/jQuz9Xjj+Enhz9pIsFT+XdQ6oxzNFzNcftEYm0u4Hs6CuFL3 jsiyZgngaJBsWrzjmaGn/o35QWAoxiM5rpxF+1dFq4HoiSWIFf/kieimNy4LNThVjmHVyY/7 Xs9Skec6VCmwzvy0s4Mn4DGAcFQAAAAAAAA= --------------ms060209040703010008000707-- From robla@lindenlab.com Thu Apr 2 00:39:08 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C8233A6A35 for ; Thu, 2 Apr 2009 00:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.953 X-Spam-Level: X-Spam-Status: No, score=-2.953 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 TsnSeUfoGlNr for ; Thu, 2 Apr 2009 00:39:07 -0700 (PDT) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id C230F3A67A8 for ; Thu, 2 Apr 2009 00:39:07 -0700 (PDT) Received: from [192.168.1.108] (c-98-232-63-20.hsd1.wa.comcast.net [98.232.63.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 076853DBC448; Thu, 2 Apr 2009 00:40:08 -0700 (PDT) Message-ID: <49D46BD8.6010403@lindenlab.com> Date: Thu, 02 Apr 2009 00:40:08 -0700 From: Rob Lanphier User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: Jason Giglio References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <49D4628B.9050207@gmail.com> In-Reply-To: <49D4628B.9050207@gmail.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 07:39:08 -0000 On 04/02/2009 12:00 AM, Jason Giglio wrote > My suggestion is that it's not appropriate to talk about client > identity, trust, or authentication as a service to be provided in a > centralized manner. > > The rest of the Internet gets along just fine without it. Sure I can > get a CA to sign something that says I am who I am, but no one much > cares; the rest of the net has routed around the problem of client > identification. I'm not sure why we would need to tackle something so > fundamentally difficult here, when it's not really necessary. > The cost of building an online identity in a virtual world is much higher than the cost of building an online identity for purposes of most web applications. That said, there's no reason to believe that this group can't come up with modes of operation for OGP such that a web-like identity-free case is possible. Rob From morgaine.dinova@googlemail.com Thu Apr 2 03:32:05 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77DEF3A6A5A for ; Thu, 2 Apr 2009 03:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.729 X-Spam-Level: X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] 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 WxmcyAvwgzeb for ; Thu, 2 Apr 2009 03:32:03 -0700 (PDT) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id 194B23A6847 for ; Thu, 2 Apr 2009 03:32:02 -0700 (PDT) Received: by ewy9 with SMTP id 9so465615ewy.37 for ; Thu, 02 Apr 2009 03:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=70Oso9H+BIM6i6uL1AHgJrUyDmb205EdFwH9GYXc4PU=; b=txi8QbW4vnjy/p2FFwv2rubM9OqOwAU4ia0fKwsiCbFd6KJF6eYXKAI9q/YYuykDsE YnaYLQkO5LZt5Y85YnnZ6LP1ErAPuj/tinlaMoqdLc+6ByyS+p5bDz1N5BzjE6Ad9eIg UFhc9fuBsWmrKUFVWXYa+GDOP4ZCFfY4P4pKg= 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=g+D/mgwxHlpoS/u3F97VYpqtC1oTNl9ynC20KMjZkhaKz5AJkzj3tPdlV1PNxbuBB1 GaKUv28qQDGkCYINkdJPJbmEx62CDYPXWfT43A06DjcOh0M5Oc2WBYruT1f98dZlVAyZ E0LR0GSFs6jsjVqJ4zqH9nBlqQuQp4GOnL2mA= MIME-Version: 1.0 Received: by 10.216.10.210 with SMTP id 60mr2961296wev.81.1238668383241; Thu, 02 Apr 2009 03:33:03 -0700 (PDT) In-Reply-To: References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> Date: Thu, 2 Apr 2009 11:33:03 +0100 Message-ID: From: Morgaine To: "Meadhbh Hamrick (Infinity)" Content-Type: multipart/alternative; boundary=0016364d31f9fa468e04668ff4fc Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 10:32:05 -0000 --0016364d31f9fa468e04668ff4fc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Thu, Apr 2, 2009 at 12:53 AM, Meadhbh Hamrick (Infinity) < infinity@lindenlab.com> wrote: > > John quoted>>> There will be millions of worlds in an Internet-scale metaverse, which >>> makes the concept of interop through trust agreements far too narrow. Trust >>> loses its meaning entirely when scaled to millions, becoming mere paperwork >>> or "security theater". >>> >> > +1. what's your suggestion? > > Jason's suggestionwas accurate I believe, namely that centralized control of identity, trust and authentication is neither appropriate nor accepted on an Internet scale. To that I'll add another suggestion, based on my experience in the defense industry. Trust agreements *between* organizations are only useful in the context of transactions *at the level of* organizations, but are very inappropriate for dealing with transactions at other (lower or higher) levels: a single credential cannot carry an appropriate semantic for dealing with multiple levels of trust, secrecy, or security --- that's why single level credentials are never used in defense organizations. In our area, VWs perform transactions over a huge range of objects that have highly diverse sensitivities, ranging from no sensitivity at all up to (presumably) the highest levels of sensitivity demanded by business, finance and government. To try to encapsulate this in a single trust agreement between interoperating worlds just doesn't make sense. Different levels of trust actually cost different amounts of money to implement if they are to be meaningful, so you cannot have a blanket trust agreement that operates at all sensitivity levels unless you place a prohibitively high bar on entry. And if you don't mandate this high bar, then the whole agreement becomes "best effort only" and so you end up with the "security theater " that I mentioned in John's quote in the context of Internet-size scaling. In view of the above two problems with trust agreements and also Jason's point, I believe that trust agreements don't actually have a useful role to play in VWs at all. Instead, I suggest that the machinery that was going to underpin trust agreements be used only for endpoint identification in the usual way, with no trust implied. It then becomes a *local policy decision*which data to release to the peer, and that policy decision will need to be made on the basis of concrete realities rather than based on the wishful thinking of a trust agreement. While we are not concerned with local policy decisions in MMOX, I think it's fair to suggest that most such decisions should err on the side of caution. The above picture would not be complete without offering a solution for those who *do* require sensitive data to be made available to parties in remote worlds, as will be common in business. Because trust between worlds is largely meaningless yet secure object transfer is still needed, I suggest that one of the many well-designed cryptographic technologies be used to deliver individually encrypted items to their intended parties directly. Whether or not a MMOX protocol should assist in the transport of such opaque items between worlds is an interesting topic for discussion. This is probably appropriate material for the same design team that will deal with VW privacy and end-to-end encrypted communications to consider. (PS. For the benefit of those who do not work in this area, please note that what's become known as "DRM" is not correct usage of cryptography and should not be used where real security is required.) Morgaine. On Thu, Apr 2, 2009 at 12:53 AM, Meadhbh Hamrick (Infinity) < infinity@lindenlab.com> wrote: > > On Apr 1, 2009, at 1:56 PM, Hurliman, John wrote: > > A few days ago I posted an e-mail highlighting my concerns with the >> architecture of OGP. I'm not sure if there was an implicit agreement from >> the OGP authors or if the e-mail was lost in the flood. I'm reposting in a >> new thread because I want to make sure I have a proper understanding of the >> architecture. >> >> >> * Indirectly, it highlights that the Agent Domain model does not >>> have a solution to the problem of accessing worlds with which there is >>> no trust agreement. People will want to enter arbitrary worlds, and >>> therefore that restriction is inadequate. >>> >> > i would guess the solution would be to have a promiscuous agent domain that > has a "i will trust all worlds" settings. i think this is a limitation of > the implementation, not the architecture. > > * There will be millions of worlds in an Internet-scale metaverse, >>> which makes the concept of interop through trust agreements far too >>> narrow. Trust loses its meaning entirely when scaled to millions, >>> becoming mere paperwork or "security theater". >>> >> > +1. what's your suggestion? > > > >> This is, in my opinion, the fundamental flaw in OGP. Explicit trust maps >> (whitelists) work great when IBM wants to define policy to connect to the >> Linden Lab grid, but has no meaning and no hope of scaling when you talk >> about defining trust for millions of simulation grids and millions (or at >> least thousands) of identity providers. This is the primary reason that >> Intel and many members of the OpenSimulator/OpenMetaverse community have not >> considered OGP as a strong proposal for virtual world interoperability. If >> this understanding is not accurate, it would be helpful if an OGP author >> could step in and clear up the confusion. >> >> John >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > --0016364d31f9fa468e04668ff4fc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 2, 2009 at 12:53 AM, Meadhbh Hamrick= (Infinity) <infinity@lindenlab.com> wrote:

John quoted >>> There will be millions of worlds in an Intern= et-scale metaverse, which makes the concept of interop through trust agreem= ents far too narrow. =A0Trust loses its meaning entirely when scaled to mil= lions, becoming mere paperwork or "security theater".

+1. what's your suggestion?

=A0
Jason's suggestion was accurate I b= elieve, namely that centralized control of identity, trust and authenticati= on is neither appropriate nor accepted on an Internet scale.=A0 To that I&#= 39;ll add another suggestion, based on my experience in the defense industr= y.

Trust agreements between organizations are only useful in the co= ntext of transactions at the level of organizations, but are very in= appropriate for dealing with transactions at other (lower or higher) levels= :=A0 a single credential cannot carry an appropriate semantic for dealing w= ith multiple levels of trust, secrecy, or security --- that's why singl= e level credentials are never used in defense organizations.

In our area, VWs perform transactions over a huge range of objects that= have highly diverse sensitivities, ranging from no sensitivity at all up t= o (presumably) the highest levels of sensitivity demanded by business, fina= nce and government.=A0 To try to encapsulate this in a single trust agreeme= nt between interoperating worlds just doesn't make sense.

Different levels of trust actually cost different amounts of money to i= mplement if they are to be meaningful, so you cannot have a blanket trust a= greement that operates at all sensitivity levels unless you place a prohibi= tively high bar on entry.=A0 And if you don't mandate this high bar, th= en the whole agreement becomes "best effort only" and so you end = up with=A0 the "security theater" that I mentioned in John's quote in the = context of Internet-size scaling.

In view of the above two problems with trust agreements and also Jason&= #39;s point, I believe that trust agreements don't actually have a usef= ul role to play in VWs at all.=A0 Instead, I suggest that the machinery tha= t was going to underpin trust agreements be used only for endpoint identifi= cation in the usual way, with no trust implied.=A0 It then becomes a loc= al policy decision which data to release to the peer, and that policy d= ecision will need to be made on the basis of concrete realities rather than= based on the wishful thinking of a trust agreement.=A0 While we are not co= ncerned with local policy decisions in MMOX, I think it's fair to sugge= st that most such decisions should err on the side of caution.

The above picture would not be complete without offering a solution for= those who do require sensitive data to be made available to parties= in remote worlds, as will be common in business.=A0 Because trust between = worlds is largely meaningless yet secure object transfer is still needed, I= suggest that one of the many well-designed cryptographic technologies be u= sed to deliver individually encrypted items to their intended parties direc= tly.=A0 Whether or not a MMOX protocol should assist in the transport of su= ch opaque items between worlds is an interesting topic for discussion.=A0 T= his is probably appropriate material for the same design team that will dea= l with VW privacy and end-to-end encrypted communications to consider.

(PS. For the benefit of those who do not work in this area, please note= that what's become known as "DRM" is not correct usage of cr= yptography and should not be used where real security is required.)


Morgaine.







On Thu, Apr 2, 2009 at 12:53 AM, Meadhbh Hamrick (Infinity) <infinity@lindenlab.com> wrote:

On Apr 1, 2009, at 1:56 PM, Hurliman, John wrote:

A few days ago I posted an e-mail highlighting my concerns with the archite= cture of OGP. I'm not sure if there was an implicit agreement from the = OGP authors or if the e-mail was lost in the flood. I'm reposting in a = new thread because I want to make sure I have a proper understanding of the= architecture.


* =A0 =A0 =A0 Indirectly, it highlights that the Agent Domain model does no= t
have a solution to the problem of accessing worlds with which there is
no trust agreement. =A0People will want to enter arbitrary worlds, and
therefore that restriction is inadequate.

i would guess the solution would be to have a promiscuous agent domain that= has a "i will trust all worlds" settings. i think this is a limi= tation of the implementation, not the architecture.

* =A0 =A0 =A0 There will be millions of worlds in an Internet-scale metaver= se,

which makes the concept of interop through trust agreements far too
narrow. =A0Trust loses its meaning entirely when scaled to millions,
becoming mere paperwork or "security theater".

+1. what's your suggestion?



This is, in my opinion, the fundamental flaw in OGP. Explicit trust maps (w= hitelists) work great when IBM wants to define policy to connect to the Lin= den Lab grid, but has no meaning and no hope of scaling when you talk about= defining trust for millions of simulation grids and millions (or at least = thousands) of identity providers. This is the primary reason that Intel and= many members of the OpenSimulator/OpenMetaverse community have not conside= red OGP as a strong proposal for virtual world interoperability. If this un= derstanding is not accurate, it would be helpful if an OGP author could ste= p in and clear up the confusion.

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

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

--0016364d31f9fa468e04668ff4fc-- From lenglish5@cox.net Thu Apr 2 06:14:01 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5D533A68E4 for ; Thu, 2 Apr 2009 06:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.848 X-Spam-Level: X-Spam-Status: No, score=0.848 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_50=0.001, 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 WRsJJl9WJ2Pc for ; Thu, 2 Apr 2009 06:14:01 -0700 (PDT) Received: from fed1rmmtao101.cox.net (fed1rmmtao101.cox.net [68.230.241.45]) by core3.amsl.com (Postfix) with ESMTP id 21E863A6885 for ; Thu, 2 Apr 2009 06:14:01 -0700 (PDT) Received: from fed1rmimpo03.cox.net ([70.169.32.75]) by fed1rmmtao101.cox.net (InterMail vM.7.08.02.01 201-2186-121-102-20070209) with ESMTP id <20090402131501.GRZX27308.fed1rmmtao101.cox.net@fed1rmimpo03.cox.net> for ; Thu, 2 Apr 2009 09:15:01 -0400 Received: from Macintosh.local ([72.200.120.202]) by fed1rmimpo03.cox.net with bizsmtp id adF21b0044N6T0Q04dF2Fl; Thu, 02 Apr 2009 09:15:02 -0400 X-Authority-Analysis: v=1.0 c=1 a=UHVKmX7V6VYA:10 a=Lur3NmvnCQ4A:10 a=Wajolswj7cQA:10 a=QMP3qD6mZ2EgzGyEqzsA:9 a=UbBDYD7khLJLAOzC4O7YYpC92RAA:4 a=by2dKgXnggYA:10 X-CM-Score: 0.00 Message-ID: <49D4BA56.8090607@cox.net> Date: Thu, 02 Apr 2009 06:15:02 -0700 From: Lawson English User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "mmox@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mmox] python client discussion group in Second Life X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: lenglish5@cox.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 13:14:01 -0000 hey all, a reminder for anyone interested in the python second life client, pyogp, we have our own irc channel on freenode called pyogp, and our own in-world discussion group, also called pyogp. Lawson (Saijanai in Second Life) From jwatte@gmail.com Thu Apr 2 09:18:58 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B77163A681D for ; Thu, 2 Apr 2009 09:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 vjvlifrJDdzZ for ; Thu, 2 Apr 2009 09:18:58 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.224]) by core3.amsl.com (Postfix) with ESMTP id 12E8E3A6917 for ; Thu, 2 Apr 2009 09:18:58 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so616957rvb.49 for ; Thu, 02 Apr 2009 09:19:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=d3qwpbhzIeIBymjnhKGO4byCKc1jDbChLsOy3Oudxc0=; b=JRIhdrMVg50UYbPXJ/+PxietDFLKqVAtJL5CohqN4n8Ib6L+WwOne5OIrgedoG6UnB n/+ycrna8HvGtKllYaUXPpmv6ZkbeuQMV8gXKIFDoxKgd7odlIwWtaKOBSwpN37hxnz6 /7ur6SJgjo5H7yWzQ2RE3VULLvk0hifUJWoLU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=uD48XhnKlGHGZwyG7lLlBxtwjKywkUKeWBO/imLKnglMUvuHT3KyuzG2k6lauccG3n frNH1OsUsy3TxakgDal1XaPHZevP6hrky+FWjjoKvvkvVKUCaTRxLMOn57hFPt/DZD7n 2PAVN27yAWv6R0H2qQjMHPnazESC1aSGFMTG8= Received: by 10.140.132.3 with SMTP id f3mr76315rvd.21.1238689199579; Thu, 02 Apr 2009 09:19:59 -0700 (PDT) Received: from ?10.10.111.233? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id k2sm3678919rvb.34.2009.04.02.09.19.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 02 Apr 2009 09:19:59 -0700 (PDT) Message-ID: <49D4E5AF.2030301@gmail.com> Date: Thu, 02 Apr 2009 09:19:59 -0700 From: Jon Watte User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <49D40A06.7030708@gmail.com> <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> <49D4295C.2020502@gmail.com> <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> In-Reply-To: <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 16:18:58 -0000 Meadhbh Hamrick (Infinity) wrote: > so maybe we might say "virtual world avatar interop" or "virtual world > event stream interop"? > > but not say "virtual world interop" 'cause it's too vague? > That's the gist of what I'm saying! Sincerely, jw From jwatte@gmail.com Thu Apr 2 09:37:16 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E82B23A69A8 for ; Thu, 2 Apr 2009 09:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 1AQKmVYTAhD1 for ; Thu, 2 Apr 2009 09:37:16 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.239]) by core3.amsl.com (Postfix) with ESMTP id 273A33A6917 for ; Thu, 2 Apr 2009 09:37:16 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so624447rvb.49 for ; Thu, 02 Apr 2009 09:38:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=tRlv6yIIfevEBAJ6yaDB0iJH3Z2CMBkBpG2ln5szs8Q=; b=NIzcdaKWcltp2k4MuML4rZrfQlL8lFQGgv+u7Dg4cxpBXzYHqMajn/oxPvqEbxOkIF sFKAbzVOS+hHSj76CYF6QqF2+ap9vzuWmbDomeyghcDS0bkwecgaVwnsBlHLCWNRYShK /6yS+2omCt58Uwam4SXtkNJPUFEZaFhkcusMc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=DJaIr0iGUxybGvKGnKUp9Va/Ykp9bhtIMs7EgK+Sy6oY3ryOYCHsdGtU5F9zZey0C4 NNLLhYtpkb6tZZXj3gG18gzXbtyrQQXx6GI+9FVrIeWQap7AKBPH+rjemTJ5pxn+k6uk kXH4G9YKqc+Ea+NVpSQ+h7FOqPlK7yGRLes04= Received: by 10.141.43.19 with SMTP id v19mr76289rvj.115.1238690297603; Thu, 02 Apr 2009 09:38:17 -0700 (PDT) Received: from ?10.10.111.233? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id k37sm3678264rvb.48.2009.04.02.09.38.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 02 Apr 2009 09:38:17 -0700 (PDT) Message-ID: <49D4E9F8.6050505@gmail.com> Date: Thu, 02 Apr 2009 09:38:16 -0700 From: Jon Watte User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Jason Giglio References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <49D4628B.9050207@gmail.com> In-Reply-To: <49D4628B.9050207@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 16:37:17 -0000 Jason Giglio wrote: > My suggestion is that it's not appropriate to talk about client > identity, trust, or authentication as a service to be provided in a > centralized manner. > > Let's look at the text-based, non-interactive web: OpenID is a service, and it is "centralized" in the sense that an OpenID provider is a central service provider. E-mail is a service, and it is "centralized" in the sense that an e-mail address is centralized to that provider. When I sign up for a web site, typically I enter an e-mail address and a password, and I then have to click on a link sent to that e-mail address. This verifies that I am at least marginally reachable through that e-mail address. This establishes identity, albeit tenuous. However, if I want to show at amazon.com, I have to provide another identity: my credit card number. This is an identity with significantly higher bar to accreditation. Some sites, like those where there is legal ramifications to providing service to under-age visitors, actually use the credit card identity even for site access, because they have higher requirements on the identity they interact with. What, if anything, in this model do you think would be different for virtual worlds, when it is real-time 3D based? Sincerely, jw > The rest of the Internet gets along just fine without it. Sure I can > get a CA to sign something that says I am who I am, but no one much > cares; the rest of the net has routed around the problem of client > identification. I'm not sure why we would need to tackle something so > fundamentally difficult here, when it's not really necessary. > > -Jason > > ------------------------------------------------------------------------ > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From cs@comlounge.net Thu Apr 2 13:04:52 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 912FB3A6D4F for ; Thu, 2 Apr 2009 13:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.216 X-Spam-Level: X-Spam-Status: No, score=-2.216 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, J_CHICKENPOX_36=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 jcYmR9LljDIm for ; Thu, 2 Apr 2009 13:04:51 -0700 (PDT) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id C2B7C3A6CAE for ; Thu, 2 Apr 2009 13:04:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 40A416F4011; Thu, 2 Apr 2009 22:05:18 +0200 (CEST) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LF2gVMtgfUfD; Thu, 2 Apr 2009 22:05:17 +0200 (CEST) Received: from [192.168.2.101] (pC19EBF8B.dip.t-dialin.net [193.158.191.139]) by post.comlounge.net (Postfix) with ESMTP id 9BD451CE00CC; Thu, 2 Apr 2009 22:05:16 +0200 (CEST) Message-ID: <49D51A7D.8000104@comlounge.net> Date: Thu, 02 Apr 2009 22:05:17 +0200 From: Christian Scholz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Jon Watte References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <49D40A06.7030708@gmail.com> <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> <49D4295C.2020502@gmail.com> <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> <49D4E5AF.2030301@gmail.com> In-Reply-To: <49D4E5AF.2030301@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 20:04:52 -0000 Jon Watte schrieb: > Meadhbh Hamrick (Infinity) wrote: >> so maybe we might say "virtual world avatar interop" or "virtual world >> event stream interop"? >> >> but not say "virtual world interop" 'cause it's too vague? I would say that in fact we have quite a few areas where interoperability is possible if we start to cut the problem space into smaller chunks. Here are some: - Identification (who is this agent?) - Profiles (information about the logged in user) - friends/contacts (probably most worlds have this) - group memberships (not every world might have this) - (instant) messaging - presence - Assets such as textures/photos/sounds etc. Now if you take those than we can discuss what interoperability means for each of them. In fact there are many formats/protocols already available: - OpenID, InformationCards etc. for identification - OpenSocial RESTful API or PortableContacts (the same protocol) for profile and contacts (in a limited fashion at least) - XMPP or IRC (and other proprietary formats) for instant messaging. Might also include presence although maybe this needs to be extended. - SMTP for not so instant messaging So in fact for some areas interoperability would already be possible. It would at least allow a user with an account on service A to login to service B and maybe be able to match contacts, chat with people on other services and so on. And basically what is describes then is a simple social network. If you add 3D services on top then you have your virtual world and this is where it becomes complicated. If you take the above elements you also have an Agent Domain. So in fact it's nothing else than the social networking part where the Region domain would be those additional 3D services. Of course the AD also does a bit more, like trust brokering. The thing is though: Why group all this together into one big chunk? It will be more likely in the future that you will have data stored on several services: your profile might be on MySpace (or one of many), you chat via IRC on freenode, you have photos on flickr which you might want to use as textures. So IMHO it makes sense to allow this to be split up into several services. The only question is how to bind this together. I already mentioned XRDS here once, which is basically a list of type URI/service URI pairs. A user could describe via XRDS where profile, friends list etc. is stored and the client or the simulator could then go and fetch it. No big Agent Domain would be needed and you also could support various services where client and simulator could choose those they understand. The only thing of course where it gets tricky is authorization brokering. You don't want your data public (at least not all of it). OAuth might give you some means of authorizing third parties to give out data on your behalf. But the problem is of course that you'd need to authorize each service individually which is not user friendly. So here is where some thinking is actually needed: How can an authorization broker be implemented. I would prefer it be OAuth based because libraries and understanding of OAuth is there (and of course it's also at the IETF ;-). And maybe we come back here to the original scalability problem of the AgentDomain but at least it would be only one problem for the AD to solve (although the name might be not correct anymore then because all the stuff related to an agent would be spread across different services). As for naming though: it would then be - profile interop - contactlist interop - group interop - chat interop etc. The question to the group would now be: Would it be worthwhile to try to use all those existing specifications and just build a way around them to bundle those things? IMHO the implementation wouldn't be so hard to do. It would be an area though where it's very mixed with where the web/social networks are going so it would make sense to do this together with web folks. -- Christian -- COM.lounge GmbH http://comlounge.net Hanbrucher Strasse 33, 52064 Aachen Amtsgericht Aachen HRB 15170 Geschäftsführer: Dr. Ben Scheffler, Christian Scholz email: info@comlounge.net fon: +49-241-4007300 fax: +49-241-97900850 personal email: cs@comlounge.net personal blog: http://mrtopf.de/blog personal podcasts: http://openweb-podcast.de, http://datawithoutborders.net From john.hurliman@intel.com Thu Apr 2 14:02:02 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CC3F3A6D78 for ; Thu, 2 Apr 2009 14:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.124 X-Spam-Level: X-Spam-Status: No, score=-6.124 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, J_CHICKENPOX_36=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 rR0-Dub2RzZq for ; Thu, 2 Apr 2009 14:02:00 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by core3.amsl.com (Postfix) with ESMTP id B3A063A6D5B for ; Thu, 2 Apr 2009 14:02:00 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 02 Apr 2009 13:55:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.39,315,1235980800"; d="scan'208";a="503131880" Received: from rrsmsx602.amr.corp.intel.com ([10.31.0.33]) by orsmga001.jf.intel.com with ESMTP; 02 Apr 2009 14:02:32 -0700 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx602.amr.corp.intel.com ([10.31.0.33]) with mapi; Thu, 2 Apr 2009 15:03:01 -0600 From: "Hurliman, John" To: Christian Scholz , Jon Watte Date: Thu, 2 Apr 2009 15:02:54 -0600 Thread-Topic: [mmox] OGP scalability concerns Thread-Index: AcmzznApde+pkxIpSJGcnuj/xum2KAABlpKg Message-ID: <62BFE5680C037E4DA0B0A08946C0933D7B6934A3@rrsmsx506.amr.corp.intel.com> References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <49D40A06.7030708@gmail.com> <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> <49D4295C.2020502@gmail.com> <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> <49D4E5AF.2030301@gmail.com> <49D51A7D.8000104@comlounge.net> In-Reply-To: <49D51A7D.8000104@comlounge.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 21:02:02 -0000 Thank you Christian, I think this is the right approach. Using partially de= fined blanket terms such as "Agent Domain" or "Region Domain" conjure up di= fferent ideas in everyone's head and also tend to imply an unnecessary aggr= egation of services. If we can clearly define the actual work items such as= identity, authentication, authorization, asset storage, asset representati= on (content types and metadata), communication and contact lists, etc. we w= ould likely find much more common ground between parties and could start pa= rtitioning the work into manageable sized chunks. John > -----Original Message----- > From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf=20 > Of Christian Scholz > Sent: Thursday, April 02, 2009 1:05 PM > To: Jon Watte > Cc: mmox@ietf.org > Subject: Re: [mmox] OGP scalability concerns >=20 > Jon Watte schrieb: >> Meadhbh Hamrick (Infinity) wrote: >>> so maybe we might say "virtual world avatar interop" or "virtual >>> world event stream interop"? >>>=20 >>> but not say "virtual world interop" 'cause it's too vague? >=20 > I would say that in fact we have quite a few areas where > interoperability is possible if we start to cut the problem space into > smaller chunks. >=20 > Here are some: >=20 > - Identification (who is this agent?) > - Profiles (information about the logged in user) > - friends/contacts (probably most worlds have this) > - group memberships (not every world might have this) > - (instant) messaging > - presence > - Assets such as textures/photos/sounds etc. >=20 > Now if you take those than we can discuss what interoperability means > for each of them. In fact there are many formats/protocols already > available: >=20 > - OpenID, InformationCards etc. for identification > - OpenSocial RESTful API or PortableContacts (the same protocol) for > profile and contacts (in a limited fashion at least) > - XMPP or IRC (and other proprietary formats) for instant messaging. > Might also include presence although maybe this needs to be extended. > - SMTP for not so instant messaging >=20 > So in fact for some areas interoperability would already be possible. > It would at least allow a user with an account on service A to login > to service B and maybe be able to match contacts, chat with people on > other services and so on. >=20 > And basically what is describes then is a simple social network. If > you add 3D services on top then you have your virtual world and this > is where it becomes complicated. >=20 > If you take the above elements you also have an Agent Domain. So in > fact it's nothing else than the social networking part where the > Region domain would be those additional 3D services. >=20 > Of course the AD also does a bit more, like trust brokering. >=20 > The thing is though: Why group all this together into one big chunk? > It will be more likely in the future that you will have data stored on > several services: your profile might be on MySpace (or one of many), > you > chat via IRC on freenode, you have photos on flickr which you might > want to use as textures. So IMHO it makes sense to allow this to be > split up into several services. The only question is how to bind this > together. >=20 > I already mentioned XRDS here once, which is basically a list of type > URI/service URI pairs. A user could describe via XRDS where profile, > friends list etc. is stored and the client or the simulator could then > go and fetch it. No big Agent Domain would be needed and you also > could support various services where client and simulator could choose > those they understand. >=20 > The only thing of course where it gets tricky is authorization > brokering. You don't want your data public (at least not all of it). > OAuth might give you some means of authorizing third parties to give > out > data on your behalf. But the problem is of course that you'd need to > authorize each service individually which is not user friendly. >=20 > So here is where some thinking is actually needed: How can an > authorization broker be implemented. I would prefer it be OAuth based > because libraries and understanding of OAuth is there (and of course > it's also at the IETF ;-). And maybe we come back here to the original > scalability problem of the AgentDomain but at least it would be only > one problem for the AD to solve (although the name might be not > correct anymore then because all the stuff related to an agent would > be spread across different services). >=20 >=20 > As for naming though: it would then be >=20 > - profile interop > - contactlist interop > - group interop > - chat interop >=20 > etc. >=20 > The question to the group would now be: Would it be worthwhile to try > to use all those existing specifications and just build a way around > them to bundle those things? IMHO the implementation wouldn't be so > hard to do. It would be an area though where it's very mixed with > where the web/social networks are going so it would make sense to do > this together with web folks. >=20 >=20 >=20 >=20 >=20 > -- Christian >=20 >=20 >=20 >=20 > -- > COM.lounge GmbH > http://comlounge.net > Hanbrucher Strasse 33, 52064 Aachen > Amtsgericht Aachen HRB 15170 > Gesch=E4ftsf=FChrer: Dr. Ben Scheffler, Christian Scholz >=20 > email: info@comlounge.net > fon: +49-241-4007300 > fax: +49-241-97900850 >=20 > personal email: cs@comlounge.net personal blog: http://mrtopf.de/blog > personal podcasts: http://openweb-podcast.de, > http://datawithoutborders.net >=20 > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From cs@comlounge.net Thu Apr 2 14:18:46 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F6833A69C5 for ; Thu, 2 Apr 2009 14:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.195 X-Spam-Level: X-Spam-Status: No, score=-2.195 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, J_CHICKENPOX_36=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 jWDY-aizDA2G for ; Thu, 2 Apr 2009 14:18:44 -0700 (PDT) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id DCD1F3A695F for ; Thu, 2 Apr 2009 14:18:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 370B91CE024A; Thu, 2 Apr 2009 23:19:28 +0200 (CEST) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tz90ZhpN+sCg; Thu, 2 Apr 2009 23:19:25 +0200 (CEST) Received: from [192.168.2.101] (pC19EBF8B.dip.t-dialin.net [193.158.191.139]) by post.comlounge.net (Postfix) with ESMTP id 3DF8F1CE00CC; Thu, 2 Apr 2009 23:19:25 +0200 (CEST) Message-ID: <49D52BDE.8060502@comlounge.net> Date: Thu, 02 Apr 2009 23:19:26 +0200 From: Christian Scholz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Lisa Dusseault References: <49CF1B1E.4070506@gmail.com> <49D0081E.4010007@gmail.com> <49D0D846.5010401@gmail.com> <170fa1780903300854s34da03eaq8b3ed2f7eb9c2a62@mail.gmail.com> <382d73da0903301459j308445f7uec660dab275175a1@mail.gmail.com> <49D1500C.1030604@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: MMOX-IETF , Kari Lippert , Jon Watte Subject: Re: [mmox] Creating walled gardens considered harmful X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 21:18:46 -0000 Hi1 Lisa Dusseault schrieb: > How about a very persona-oriented (specific) use case... Always good :-) > Lisa has a house in one virtual world, with virtual rooms that she > frequently hangs out in, that friends might find her at. One day she > goes to a party in another virtual world. She leaves behind a note on > her virtual door or bulletin board (she has control over the > presentation, it could be a spinning hovering party hat or a blue > police phone booth if the home world allows that). The note has a > link to the party world because it's an open party. Lisa's friends > can now find her, and the more seamless their experience in getting > from the first virtual world to the second, the more likely they are > to enjoy the experience, follow through, and see her. > > Seamless is a goal, but might involve: > - Not launching a new client, if possible, and if it is > - A transition that is not too jarring, minimizing reload > screens, blank screens, dialog boxes, choices > - Low time consumption for transport, including time navigating from > an initial destination to a final destination, if allowed by the > destination world > - Avoiding a registration step if possible, and if it is > - Lisa can recognize her friends under the moniker she'd > normally see them under So here I would say that this isn't necessarily a virtual worlds specific use case. You want to have the same on social networks without any 3D interaction. And I guess this thing people call the Open Stack (I know, it isn't a stack :-) ) is already going into that direction. In an ideal world you might simply enter e.g. your openid, you authenticate via the OP and the rest should be automatically aavailable to that virtual world: profile, friends list, inventory as long as it's compatible, chat, groups and so on. Now if we go one step further and assume that there is some mechanism to also carry on your identity without any user interaction then it should be rather seamless (but also less secure of course). How that might be implemented might be up to the group to find out. But as Eran also wanted to think about adding identity support to OAuth that might actually be possible then. > - Keeping avatar consistency to the extent possible, for recognition > as well as seamlessness Here I wonder if there couldn't at least be some very simple 3D represenation which is easy to implement, does not give you the whole experience you would get with a native client but at least could understand who is around and roughly where. > For bonus points, Lisa can open a door from her house into the party, > and visitors can get a glimpse of what's beyond, then just walk > through. Yay, a portal! :-) But maybe at least some sort of video service might also be possible where the client only needs to understand that video part in a portal but nothing else of the foreign virtual world. I am just wondering if that really makes sense if you cannot move through it. -- Christian > On Mon, Mar 30, 2009 at 4:04 PM, Jon Watte wrote: >> Kari Lippert wrote: >>> >>> >>> I've been lurking for some time now and reading and trying to understand >>> the basic user requirement that is driving this work. I have to admit this >>> is as close as I've seen. >>> >>> I understand "teleport" (and believe if you can define it well enough, >>> smart people can make it so) but it leaves me asking why? Why would a user >>> desire to "teleport" from one VWE to another? The answer to this will, I >>> believe, help you focus on what needs to be included in the definition of >>> what it means to "teleport", and what can be safely set aside for the >>> moment. >>> >>> Kari >> I think "teleport" is an implementation detail. Does this use case seem like >> a good description of what you consider a "teleport"? >> >> >> 2.1. Friend Invite >> >> >> 2.1.1. Description >> >> >> >> 1. User A uses virtual world system A that complies with MMOX >> interoperability. >> 2. User B uses virtual world system B that complies with MMOX >> interoperability. >> 3. User A wants user B to visit him/her in system/world A, and gets >> a suitable URL from his/her system (A), and sends this to user B >> using any transport (mail, IM, integrated communication, carrier >> pigeon, ...) >> 4. User B clicks/activates this link. >> 5. After a brief "loading" screen, user B sees user A in user A's >> environment, including a representative form of any simulated >> object in that environment. >> 6. User B can interact at some level with the objects from user A. >> 7. Objects that user B take out of inventory show up in some >> representative form for both user A and user B. >> 8. User A can interact at some level with any objects that user B >> bring out of inventory. >> >> >> >> Note that I assumed that if you have avatars and objects, you also have >> text/speech, but that's a poor assumption -- it should go as line 5.5 in >> this use case, I guess. >> >> Sincerely, >> >> jw >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox -- COM.lounge GmbH http://comlounge.net Hanbrucher Strasse 33, 52064 Aachen Amtsgericht Aachen HRB 15170 Geschäftsführer: Dr. Ben Scheffler, Christian Scholz email: info@comlounge.net fon: +49-241-4007300 fax: +49-241-97900850 personal email: cs@comlounge.net personal blog: http://mrtopf.de/blog personal podcasts: http://openweb-podcast.de, http://datawithoutborders.net From cs@comlounge.net Thu Apr 2 14:26:42 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 242D63A68B2 for ; Thu, 2 Apr 2009 14:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=-0.178, BAYES_00=-2.599, J_CHICKENPOX_36=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 XKLX3QNR4far for ; Thu, 2 Apr 2009 14:26:41 -0700 (PDT) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id AAE163A67AC for ; Thu, 2 Apr 2009 14:26:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 1E1C31CE024A; Thu, 2 Apr 2009 23:27:42 +0200 (CEST) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULjHYih2h2i1; Thu, 2 Apr 2009 23:27:40 +0200 (CEST) Received: from [192.168.2.101] (pC19EBF8B.dip.t-dialin.net [193.158.191.139]) by post.comlounge.net (Postfix) with ESMTP id 201AC1CE00CC; Thu, 2 Apr 2009 23:27:39 +0200 (CEST) Message-ID: <49D52DCD.2000806@comlounge.net> Date: Thu, 02 Apr 2009 23:27:41 +0200 From: Christian Scholz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Hurliman, John" References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <49D40A06.7030708@gmail.com> <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> <49D4295C.2020502@gmail.com> <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> <49D4E5AF.2030301@gmail.com> <49D51A7D.8000104@comlounge.net> <62BFE5680C037E4DA0B0A08946C0933D7B6934A3@rrsmsx506.amr.corp.intel.com> In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D7B6934A3@rrsmsx506.amr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "mmox@ietf.org" , Jon Watte Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 21:26:42 -0000 Hurliman, John schrieb: > Thank you Christian, I think this is the right approach. Using > partially defined blanket terms such as "Agent Domain" or "Region > Domain" conjure up different ideas in everyone's head and also tend > to imply an unnecessary aggregation of services. If we can clearly > define the actual work items such as identity, authentication, > authorization, asset storage, asset representation (content types and > metadata), communication and contact lists, etc. we would likely find > much more common ground between parties and could start partitioning > the work into manageable sized chunks. Thanks! In fact we could actually start with thinking about identification/authentication right away and maybe taking OpenID and see how it might fit in a not web-based environment (read: VW client). Another option would be to join forces with the OAuth group at IETF and check on how we could add identity to OAuth (there is discussion about that already). Eventually this might be an easier choice and you could do authorization in one step, at least for some centralized services. We could start by fleshing out some more detailed use cases to see what is needed, what can be provided by existing standards and what might be missing and needs some inventing. I am just too tired to start right away ;-) -- Christian > > John > >> -----Original Message----- From: mmox-bounces@ietf.org >> [mailto:mmox-bounces@ietf.org] On Behalf Of Christian Scholz Sent: >> Thursday, April 02, 2009 1:05 PM To: Jon Watte Cc: mmox@ietf.org >> Subject: Re: [mmox] OGP scalability concerns >> >> Jon Watte schrieb: >>> Meadhbh Hamrick (Infinity) wrote: >>>> so maybe we might say "virtual world avatar interop" or >>>> "virtual world event stream interop"? >>>> >>>> but not say "virtual world interop" 'cause it's too vague? >> I would say that in fact we have quite a few areas where >> interoperability is possible if we start to cut the problem space >> into smaller chunks. >> >> Here are some: >> >> - Identification (who is this agent?) - Profiles (information about >> the logged in user) - friends/contacts (probably most worlds have >> this) - group memberships (not every world might have this) - >> (instant) messaging - presence - Assets such as >> textures/photos/sounds etc. >> >> Now if you take those than we can discuss what interoperability >> means for each of them. In fact there are many formats/protocols >> already available: >> >> - OpenID, InformationCards etc. for identification - OpenSocial >> RESTful API or PortableContacts (the same protocol) for profile and >> contacts (in a limited fashion at least) - XMPP or IRC (and other >> proprietary formats) for instant messaging. Might also include >> presence although maybe this needs to be extended. - SMTP for not >> so instant messaging >> >> So in fact for some areas interoperability would already be >> possible. It would at least allow a user with an account on service >> A to login to service B and maybe be able to match contacts, chat >> with people on other services and so on. >> >> And basically what is describes then is a simple social network. If >> you add 3D services on top then you have your virtual world and >> this is where it becomes complicated. >> >> If you take the above elements you also have an Agent Domain. So in >> fact it's nothing else than the social networking part where the >> Region domain would be those additional 3D services. >> >> Of course the AD also does a bit more, like trust brokering. >> >> The thing is though: Why group all this together into one big >> chunk? It will be more likely in the future that you will have data >> stored on several services: your profile might be on MySpace (or >> one of many), you chat via IRC on freenode, you have photos on >> flickr which you might want to use as textures. So IMHO it makes >> sense to allow this to be split up into several services. The only >> question is how to bind this together. >> >> I already mentioned XRDS here once, which is basically a list of >> type URI/service URI pairs. A user could describe via XRDS where >> profile, friends list etc. is stored and the client or the >> simulator could then go and fetch it. No big Agent Domain would be >> needed and you also could support various services where client and >> simulator could choose those they understand. >> >> The only thing of course where it gets tricky is authorization >> brokering. You don't want your data public (at least not all of >> it). OAuth might give you some means of authorizing third parties >> to give out data on your behalf. But the problem is of course that >> you'd need to authorize each service individually which is not user >> friendly. >> >> So here is where some thinking is actually needed: How can an >> authorization broker be implemented. I would prefer it be OAuth >> based because libraries and understanding of OAuth is there (and of >> course it's also at the IETF ;-). And maybe we come back here to >> the original scalability problem of the AgentDomain but at least it >> would be only one problem for the AD to solve (although the name >> might be not correct anymore then because all the stuff related to >> an agent would be spread across different services). >> >> >> As for naming though: it would then be >> >> - profile interop - contactlist interop - group interop - chat >> interop >> >> etc. >> >> The question to the group would now be: Would it be worthwhile to >> try to use all those existing specifications and just build a way >> around them to bundle those things? IMHO the implementation >> wouldn't be so hard to do. It would be an area though where it's >> very mixed with where the web/social networks are going so it would >> make sense to do this together with web folks. >> >> >> >> >> >> -- Christian >> >> >> >> >> -- COM.lounge GmbH http://comlounge.net Hanbrucher Strasse 33, >> 52064 Aachen Amtsgericht Aachen HRB 15170 Geschäftsführer: Dr. Ben >> Scheffler, Christian Scholz >> >> email: info@comlounge.net fon: +49-241-4007300 fax: >> +49-241-97900850 >> >> personal email: cs@comlounge.net personal blog: >> http://mrtopf.de/blog personal podcasts: http://openweb-podcast.de, >> http://datawithoutborders.net >> >> _______________________________________________ mmox mailing list >> mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox -- COM.lounge GmbH http://comlounge.net Hanbrucher Strasse 33, 52064 Aachen Amtsgericht Aachen HRB 15170 Geschäftsführer: Dr. Ben Scheffler, Christian Scholz email: info@comlounge.net fon: +49-241-4007300 fax: +49-241-97900850 personal email: cs@comlounge.net personal blog: http://mrtopf.de/blog personal podcasts: http://openweb-podcast.de, http://datawithoutborders.net From jwatte@gmail.com Thu Apr 2 14:43:58 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 607223A6B39 for ; Thu, 2 Apr 2009 14:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 ykUI1hgDWPOo for ; Thu, 2 Apr 2009 14:43:57 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by core3.amsl.com (Postfix) with ESMTP id AC9C73A6896 for ; Thu, 2 Apr 2009 14:43:57 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so732463rvb.49 for ; Thu, 02 Apr 2009 14:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=FC524cDYiJ688IC1ad37JhdFDPcMY9gWIVz/+tWm5xk=; b=WaS+1UTQexDwCjBeCQRNjHDtAw/7Iga40ieGd5lh0ta6+UeA1socgDp4MZr42Ai6dm SH905FyX/uYr4McEZ7hAt0IrUBVcH3AwMoxabW9HGCQkv8xMQsBxsQ8QLTUwd7EWYi71 euh2Hg+Eqj9VwqEuXUAuyHNC1CaiExm0uDrkQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=W4n4U42dvRDKLRd0AbO6ccOppATTiRPesPtXXXz0dk6VnNhK2np0u/9wnaMhM7t9g8 r1iD8ShT2I0QlOB7b2RNNJVAY1droBSAMXlAUTI5BgpYkYnnROzIzekjTt62isfqQ37l lf46k4oXjg0VehBcS+/Lut8RpUWoWvn3iz+LY= Received: by 10.141.101.12 with SMTP id d12mr166934rvm.240.1238708699539; Thu, 02 Apr 2009 14:44:59 -0700 (PDT) Received: from ?10.10.111.233? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id f21sm4469097rvb.25.2009.04.02.14.44.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 02 Apr 2009 14:44:59 -0700 (PDT) Message-ID: <49D531DA.4080006@gmail.com> Date: Thu, 02 Apr 2009 14:44:58 -0700 From: Jon Watte User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Christian Scholz References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <49D40A06.7030708@gmail.com> <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> <49D4295C.2020502@gmail.com> <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> <49D4E5AF.2030301@gmail.com> <49D51A7D.8000104@comlounge.net> <62BFE5680C037E4DA0B0A08946C0933D7B6934A3@rrsmsx506.amr.corp.intel.com> <49D52DCD.2000806@comlounge.net> In-Reply-To: <49D52DCD.2000806@comlounge.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 21:43:58 -0000 Christian Scholz wrote: > Another option would be to join forces with the OAuth group at IETF > and check on how we could add identity to OAuth (there is discussion > about that already). Eventually this might be an easier choice and you > could do authorization in one step, at least for some centralized > services. The first question is: does the OAuth "callback" URL work in a VW sense? At a minimum, this means that a VW needs to have a publicly available *incoming* URL for receiving authentication tokens. For a VW behind a firewall, that's not necessarily true. (Then again, OAuth doesn't work for an intranet web site behind a firewall, either) Sincerely, jw From cs@comlounge.net Thu Apr 2 14:53:04 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C56D43A6A7C for ; Thu, 2 Apr 2009 14:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.162 X-Spam-Level: X-Spam-Status: No, score=-2.162 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_00=-2.599, J_CHICKENPOX_36=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 g3GC0dJIAhpD for ; Thu, 2 Apr 2009 14:53:03 -0700 (PDT) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 7ADD33A67A1 for ; Thu, 2 Apr 2009 14:52:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 9D86F1CE0145; Thu, 2 Apr 2009 23:53:46 +0200 (CEST) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uaCbBOT0EMV; Thu, 2 Apr 2009 23:53:45 +0200 (CEST) Received: from [192.168.2.101] (pC19EBF8B.dip.t-dialin.net [193.158.191.139]) by post.comlounge.net (Postfix) with ESMTP id 22BDF1CE00CC; Thu, 2 Apr 2009 23:53:45 +0200 (CEST) Message-ID: <49D533EA.4010301@comlounge.net> Date: Thu, 02 Apr 2009 23:53:46 +0200 From: Christian Scholz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Jon Watte References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <49D40A06.7030708@gmail.com> <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> <49D4295C.2020502@gmail.com> <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> <49D4E5AF.2030301@gmail.com> <49D51A7D.8000104@comlounge.net> <62BFE5680C037E4DA0B0A08946C0933D7B6934A3@rrsmsx506.amr.corp.intel.com> <49D52DCD.2000806@comlounge.net> <49D531DA.4080006@gmail.com> In-Reply-To: <49D531DA.4080006@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 21:53:04 -0000 Jon Watte schrieb: > Christian Scholz wrote: >> Another option would be to join forces with the OAuth group at IETF >> and check on how we could add identity to OAuth (there is discussion >> about that already). Eventually this might be an easier choice and you >> could do authorization in one step, at least for some centralized >> services. > > The first question is: does the OAuth "callback" URL work in a VW sense? > At a minimum, this means that a VW needs to have a publicly available > *incoming* URL for receiving authentication tokens. For a VW behind a > firewall, that's not necessarily true. (Then again, OAuth doesn't work > for an intranet web site behind a firewall, either) The redirect setup is only one example of obtaining the OAuth token. You can do it whatever way you want to (the new version of the spec also makes that clearer as it starts with just the way you actually do authorized requests and only explains in the second part the redirect mechanism). But if you look at e.g. iMovie and how it uploads movies to YouTube you have an example of how a desktop app can do it (although it's not using OAuth I think but probably Google AuthSub but it's basically the same). Basically instead of having a callback URL the client will simply wait until the user has finished authorization in the web browser. The server then might tell him to go back to the client and click "Continue". After that the client will contact the server again and will try to exchange the request token for an access token which only will work if the user authorized it. I am not sure though I understand the question. You might also be talking about the server being behind a firewall and not reachable by the client. But then I guess you need some ports open anyway for the client to be able to connect any way. -- Christian -- COM.lounge GmbH http://comlounge.net Hanbrucher Strasse 33, 52064 Aachen Amtsgericht Aachen HRB 15170 Geschäftsführer: Dr. Ben Scheffler, Christian Scholz email: info@comlounge.net fon: +49-241-4007300 fax: +49-241-97900850 personal email: cs@comlounge.net personal blog: http://mrtopf.de/blog personal podcasts: http://openweb-podcast.de, http://datawithoutborders.net From infinity@lindenlab.com Thu Apr 2 15:21:16 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B8873A6A71 for ; Thu, 2 Apr 2009 15:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.228 X-Spam-Level: X-Spam-Status: No, score=-3.228 tagged_above=-999 required=5 tests=[AWL=-0.229, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_LOW=-1] 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 bjeT5M6ubuyS for ; Thu, 2 Apr 2009 15:21:14 -0700 (PDT) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id DDBFC3A68DD for ; Thu, 2 Apr 2009 15:21:14 -0700 (PDT) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id A035F3DBC05E; Thu, 2 Apr 2009 15:22:16 -0700 (PDT) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: "Hurliman, John" In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D7B6934A3@rrsmsx506.amr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 2 Apr 2009 15:22:16 -0700 References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <49D40A06.7030708@gmail.com> <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> <49D4295C.2020502@gmail.com> <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> <49D4E5AF.2030301@gmail.com> <49D51A7D.8000104@comlounge.net> <62BFE5680C037E4DA0B0A08946C0933D7B6934A3@rrsmsx506.amr.corp.intel.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" , Jon Watte Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 22:21:16 -0000 i think the way we were initially thinking about it is that "the agent =20= domain" is the group of systems / interfaces that house information =20 unique to or focused on agent based services while the "region domain" =20= was the hypothetical place where virtual space based services lived. =20 we proposed that division because services like identity, profiles, =20 groups, presence, affiliation, group or proximal chat, item scheduling =20= (i.e. - rezzing), avatar movement and instantiation, etc. all =20 generally scale along the agent or virtual land / space axis. (they =20 DEFINITELY do in second lifelike systems, and i would argue they also =20= do in most other architectures.) in our nomenclature, we would =20 probably refer to IM, presence, etc. as being "services" of the domain =20= which most constrains their scaling behavior. so for example, if you built a group IM system that requires you to =20 authenticate yourself to whomever manages your virtual identity, the =20 servers on the back end would encounter scaling problems as the number =20= of groups (and presumably also the number of agents) grew. that's why =20= _we_ call group IM an agent domain service. we also use the term "domain" in it's more traditional sense to imply =20= a bounds of authority. which is to say, we assume that all hosts and =20 services inside a domain are administered by the same entity. that =20 being said, there's no reason you can't have sub-domains, and there's =20= no reason that two services associated with "the" agent domain can't =20 be split across two administrative domains (like maybe yahoo or AOL =20 get in the business of moving virtual world IM messages but don't want =20= to deploy a world themselves.) it would require some coordination of =20 identity management issues, but i'm sure they're tractable. On Apr 2, 2009, at 2:02 PM, Hurliman, John wrote: > Thank you Christian, I think this is the right approach. Using =20 > partially defined blanket terms such as "Agent Domain" or "Region =20 > Domain" conjure up different ideas in everyone's head and also tend =20= > to imply an unnecessary aggregation of services. If we can clearly =20 > define the actual work items such as identity, authentication, =20 > authorization, asset storage, asset representation (content types =20 > and metadata), communication and contact lists, etc. we would likely =20= > find much more common ground between parties and could start =20 > partitioning the work into manageable sized chunks. > > John > >> -----Original Message----- >> From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf >> Of Christian Scholz >> Sent: Thursday, April 02, 2009 1:05 PM >> To: Jon Watte >> Cc: mmox@ietf.org >> Subject: Re: [mmox] OGP scalability concerns >> >> Jon Watte schrieb: >>> Meadhbh Hamrick (Infinity) wrote: >>>> so maybe we might say "virtual world avatar interop" or "virtual >>>> world event stream interop"? >>>> >>>> but not say "virtual world interop" 'cause it's too vague? >> >> I would say that in fact we have quite a few areas where >> interoperability is possible if we start to cut the problem space =20 >> into >> smaller chunks. >> >> Here are some: >> >> - Identification (who is this agent?) >> - Profiles (information about the logged in user) >> - friends/contacts (probably most worlds have this) >> - group memberships (not every world might have this) >> - (instant) messaging >> - presence >> - Assets such as textures/photos/sounds etc. >> >> Now if you take those than we can discuss what interoperability means >> for each of them. In fact there are many formats/protocols already >> available: >> >> - OpenID, InformationCards etc. for identification >> - OpenSocial RESTful API or PortableContacts (the same protocol) for >> profile and contacts (in a limited fashion at least) >> - XMPP or IRC (and other proprietary formats) for instant messaging. >> Might also include presence although maybe this needs to be extended. >> - SMTP for not so instant messaging >> >> So in fact for some areas interoperability would already be possible. >> It would at least allow a user with an account on service A to login >> to service B and maybe be able to match contacts, chat with people on >> other services and so on. >> >> And basically what is describes then is a simple social network. If >> you add 3D services on top then you have your virtual world and this >> is where it becomes complicated. >> >> If you take the above elements you also have an Agent Domain. So in >> fact it's nothing else than the social networking part where the >> Region domain would be those additional 3D services. >> >> Of course the AD also does a bit more, like trust brokering. >> >> The thing is though: Why group all this together into one big chunk? >> It will be more likely in the future that you will have data stored =20= >> on >> several services: your profile might be on MySpace (or one of many), >> you >> chat via IRC on freenode, you have photos on flickr which you might >> want to use as textures. So IMHO it makes sense to allow this to be >> split up into several services. The only question is how to bind this >> together. >> >> I already mentioned XRDS here once, which is basically a list of type >> URI/service URI pairs. A user could describe via XRDS where profile, >> friends list etc. is stored and the client or the simulator could =20 >> then >> go and fetch it. No big Agent Domain would be needed and you also >> could support various services where client and simulator could =20 >> choose >> those they understand. >> >> The only thing of course where it gets tricky is authorization >> brokering. You don't want your data public (at least not all of it). >> OAuth might give you some means of authorizing third parties to give >> out >> data on your behalf. But the problem is of course that you'd need to >> authorize each service individually which is not user friendly. >> >> So here is where some thinking is actually needed: How can an >> authorization broker be implemented. I would prefer it be OAuth based >> because libraries and understanding of OAuth is there (and of course >> it's also at the IETF ;-). And maybe we come back here to the =20 >> original >> scalability problem of the AgentDomain but at least it would be only >> one problem for the AD to solve (although the name might be not >> correct anymore then because all the stuff related to an agent would >> be spread across different services). >> >> >> As for naming though: it would then be >> >> - profile interop >> - contactlist interop >> - group interop >> - chat interop >> >> etc. >> >> The question to the group would now be: Would it be worthwhile to try >> to use all those existing specifications and just build a way around >> them to bundle those things? IMHO the implementation wouldn't be so >> hard to do. It would be an area though where it's very mixed with >> where the web/social networks are going so it would make sense to do >> this together with web folks. >> >> >> >> >> >> -- Christian >> >> >> >> >> -- >> COM.lounge GmbH >> http://comlounge.net >> Hanbrucher Strasse 33, 52064 Aachen >> Amtsgericht Aachen HRB 15170 >> Gesch=E4ftsf=FChrer: Dr. Ben Scheffler, Christian Scholz >> >> email: info@comlounge.net >> fon: +49-241-4007300 >> fax: +49-241-97900850 >> >> personal email: cs@comlounge.net personal blog: http://mrtopf.de/blog >> personal podcasts: http://openweb-podcast.de, >> http://datawithoutborders.net >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From infinity@lindenlab.com Thu Apr 2 15:49:48 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA01B3A6CBB for ; Thu, 2 Apr 2009 15:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_LOW=-1] 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 mAvoRIIlmf99 for ; Thu, 2 Apr 2009 15:49:47 -0700 (PDT) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id BD4393A6AD4 for ; Thu, 2 Apr 2009 15:49:47 -0700 (PDT) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id E0C731414003; Thu, 2 Apr 2009 15:50:49 -0700 (PDT) From: "Meadhbh Hamrick (Infinity)" To: Christian Scholz In-Reply-To: <49D533EA.4010301@comlounge.net> References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <49D40A06.7030708@gmail.com> <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> <49D4295C.2020502@gmail.com> <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> <49D4E5AF.2030301@gmail.com><49D51A7D.8000104@comlounge.net><62BFE5680C037E4DA0B0A08946C0933D7B6934A3@rrsmsx506.amr.corp.intel .com><49D52DCD.2000806@comlounge.net> <49D531DA.4080006@gmail.com> <49D533EA.4010301@comlounge.net> Message-Id: <4DF1C9A3-6170-4448-95DD-A3C72901A53A@lindenlab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 2 Apr 2009 15:50:49 -0700 X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" , Jon Watte Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 22:49:49 -0000 yup. for what it's worth, i had several good chats with mark atwood at =20= the ietf meeting. he's coming down to the bay area for the mysql =20 conference, i hope to buy him a beer some evening and run a few =20 proposals past him wrt OAuth and it's use in OGP. and. ack. i should probably have mentioned this earlier. i got a lot =20 of good feedback about the drafts we published, and one of the things =20= that's going into the next rev of the auth draft is how to deal with =20 transport authentication ( like when your transport manages =20 authentication for you like client side certs and HTTP digest =20 (*shudder*) ). eventually OpenID should go into a similar section, but =20= we feel there are still a few open issues with it's use. declaring the =20= solution to being "we just use XRI" and declaring victory seems a =20 little hasty, but it seems like there's enough interest to warrant =20 it's inclusion in any future charter / IDs / etc. i haven't heard anyone say they have serious problems with OpenID in =20 general. i mean... if someone was implying that OpenID kills puppies, =20= i missed it. that being said, XRI / XRDS and OpenID are not in =20 universal use, so it's unlikely a statement like "OGP will only ever =20 use OpenID" will ever pass the humm test. but the statement "OpenID =20 and XRDS should forever be banished from OGP" will also never pass the =20= humm test. which is to say... if anyone's willing to do the work to figure out =20 how to wedge OpenID into OGP, i'm all for it. to be clear, in this =20 context, the word "work" means: 1. you work with other list members requirements. 2. you produce a document describing how OpenID or XRDS can be used in =20= conjunction with the existing spec (though the existing specs are cast =20= in jello, not in stone, so there's some room to modify them if we =20 absolutely have to.) 3. producing code to demonstrate it's use.. *cough*PyOGP*cough* so.. to recap.. we (LL) have made no statement about OpenID one way or =20= another. so... don't hold your breath waiting for us to deploy =20 services that consume OpenID id services. still, it's gaining in =20 popularity, so we're not going to ignore it, we want to make sure it's =20= properly applied to the problem at hand. ditto with OAuth. ditto with =20= SAML 1.1 / Shib 1.3. -cheers -meadhbh On Apr 2, 2009, at 2:53 PM, Christian Scholz wrote: > Jon Watte schrieb: >> Christian Scholz wrote: >>> Another option would be to join forces with the OAuth group at =20 >>> IETF and check on how we could add identity to OAuth (there is =20 >>> discussion about that already). Eventually this might be an easier =20= >>> choice and you could do authorization in one step, at least for =20 >>> some centralized services. >> The first question is: does the OAuth "callback" URL work in a VW =20 >> sense? At a minimum, this means that a VW needs to have a publicly =20= >> available *incoming* URL for receiving authentication tokens. For a =20= >> VW behind a firewall, that's not necessarily true. (Then again, =20 >> OAuth doesn't work for an intranet web site behind a firewall, =20 >> either) > > The redirect setup is only one example of obtaining the OAuth token. =20= > You can do it whatever way you want to (the new version of the spec =20= > also makes that clearer as it starts with just the way you actually =20= > do authorized requests and only explains in the second part the =20 > redirect mechanism). > > But if you look at e.g. iMovie and how it uploads movies to YouTube =20= > you have an example of how a desktop app can do it (although it's =20 > not using OAuth I think but probably Google AuthSub but it's =20 > basically the same). > > Basically instead of having a callback URL the client will simply =20 > wait until the user has finished authorization in the web browser. =20 > The server then might tell him to go back to the client and click =20 > "Continue". After that the client will contact the server again and =20= > will try to exchange the request token for an access token which =20 > only will work if the user authorized it. > > I am not sure though I understand the question. You might also be =20 > talking about the server being behind a firewall and not reachable =20 > by the client. But then I guess you need some ports open anyway for =20= > the client to be able to connect any way. > > -- Christian > > > > --=20 > COM.lounge GmbH > http://comlounge.net > Hanbrucher Strasse 33, 52064 Aachen > Amtsgericht Aachen HRB 15170 > Gesch=E4ftsf=FChrer: Dr. Ben Scheffler, Christian Scholz > > email: info@comlounge.net > fon: +49-241-4007300 > fax: +49-241-97900850 > > personal email: cs@comlounge.net > personal blog: http://mrtopf.de/blog > personal podcasts: http://openweb-podcast.de, = http://datawithoutborders.net > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From infinity@lindenlab.com Thu Apr 2 15:51:50 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 613FE3A6A63 for ; Thu, 2 Apr 2009 15:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.219 X-Spam-Level: X-Spam-Status: No, score=-3.219 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_LOW=-1] 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 08bpbI0-vPXn for ; Thu, 2 Apr 2009 15:51:49 -0700 (PDT) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id C070A3A6832 for ; Thu, 2 Apr 2009 15:51:48 -0700 (PDT) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id CD9D01414003; Thu, 2 Apr 2009 15:52:50 -0700 (PDT) Message-Id: <4157ED40-0960-43DB-959A-41AD795521C8@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Christian Scholz In-Reply-To: <49D533EA.4010301@comlounge.net> Content-Type: multipart/alternative; boundary=Apple-Mail-13-560049226 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 2 Apr 2009 15:52:50 -0700 References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <49D40A06.7030708@gmail.com> <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> <49D4295C.2020502@gmail.com> <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> <49D4E5AF.2030301@gmail.com><49D51A7D.8000104@comlounge.net><62BFE5680C037E4DA0B0A08946C0933D7B6934A3@rrsmsx506.amr.corp.intel .com><49D52DCD.2000806@comlounge.net> <49D531DA.4080006@gmail.com> <49D533EA.4010301@comlounge.net> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" , Jon Watte Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 22:51:50 -0000 --Apple-Mail-13-560049226 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable krunk. i am totally having email problems. apologies if this is a =20 duplicate. yup. for what it's worth, i had several good chats with mark atwood at =20= the ietf meeting. he's coming down to the bay area for the mysql =20 conference, i hope to buy him a beer some evening and run a few =20 proposals past him wrt OAuth and it's use in OGP. and. ack. i should probably have mentioned this earlier. i got a lot =20 of good feedback about the drafts we published, and one of the things =20= that's going into the next rev of the auth draft is how to deal with =20 transport authentication ( like when your transport manages =20 authentication for you like client side certs and HTTP digest =20 (*shudder*) ). eventually OpenID should go into a similar section, but =20= we feel there are still a few open issues with it's use. declaring the =20= solution to being "we just use XRI" and declaring victory seems a =20 little hasty, but it seems like there's enough interest to warrant =20 it's inclusion in any future charter / IDs / etc. i haven't heard anyone say they have serious problems with OpenID in =20 general. i mean... if someone was implying that OpenID kills puppies, =20= i missed it. that being said, XRI / XRDS and OpenID are not in =20 universal use, so it's unlikely a statement like "OGP will only ever =20 use OpenID" will ever pass the humm test. but the statement "OpenID =20 and XRDS should forever be banished from OGP" will also never pass the =20= humm test. which is to say... if anyone's willing to do the work to figure out =20 how to wedge OpenID into OGP, i'm all for it. to be clear, in this =20 context, the word "work" means: 1. you work with other list members requirements. 2. you produce a document describing how OpenID or XRDS can be used in =20= conjunction with the existing spec (though the existing specs are cast =20= in jello, not in stone, so there's some room to modify them if we =20 absolutely have to.) 3. producing code to demonstrate it's use.. *cough*PyOGP*cough* so.. to recap.. we (LL) have made no statement about OpenID one way or =20= another. so... don't hold your breath waiting for us to deploy =20 services that consume OpenID id services. still, it's gaining in =20 popularity, so we're not going to ignore it, we want to make sure it's =20= properly applied to the problem at hand. ditto with OAuth. ditto with =20= SAML 1.1 / Shib 1.3. -cheers -meadhbh On Apr 2, 2009, at 2:53 PM, Christian Scholz wrote: > Jon Watte schrieb: >> Christian Scholz wrote: >>> Another option would be to join forces with the OAuth group at =20 >>> IETF and check on how we could add identity to OAuth (there is =20 >>> discussion about that already). Eventually this might be an easier =20= >>> choice and you could do authorization in one step, at least for =20 >>> some centralized services. >> The first question is: does the OAuth "callback" URL work in a VW =20 >> sense? At a minimum, this means that a VW needs to have a publicly =20= >> available *incoming* URL for receiving authentication tokens. For a =20= >> VW behind a firewall, that's not necessarily true. (Then again, =20 >> OAuth doesn't work for an intranet web site behind a firewall, =20 >> either) > > The redirect setup is only one example of obtaining the OAuth token. =20= > You can do it whatever way you want to (the new version of the spec =20= > also makes that clearer as it starts with just the way you actually =20= > do authorized requests and only explains in the second part the =20 > redirect mechanism). > > But if you look at e.g. iMovie and how it uploads movies to YouTube =20= > you have an example of how a desktop app can do it (although it's =20 > not using OAuth I think but probably Google AuthSub but it's =20 > basically the same). > > Basically instead of having a callback URL the client will simply =20 > wait until the user has finished authorization in the web browser. =20 > The server then might tell him to go back to the client and click =20 > "Continue". After that the client will contact the server again and =20= > will try to exchange the request token for an access token which =20 > only will work if the user authorized it. > > I am not sure though I understand the question. You might also be =20 > talking about the server being behind a firewall and not reachable =20 > by the client. But then I guess you need some ports open anyway for =20= > the client to be able to connect any way. > > -- Christian > > > > --=20 > COM.lounge GmbH > http://comlounge.net > Hanbrucher Strasse 33, 52064 Aachen > Amtsgericht Aachen HRB 15170 > Gesch=E4ftsf=FChrer: Dr. Ben Scheffler, Christian Scholz > > email: info@comlounge.net > fon: +49-241-4007300 > fax: +49-241-97900850 > > personal email: cs@comlounge.net > personal blog: http://mrtopf.de/blog > personal podcasts: http://openweb-podcast.de, = http://datawithoutborders.net > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --Apple-Mail-13-560049226 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
krunk. i am totally having email problems. = apologies if this is a duplicate.

yup. = for what it's worth, i had several good chats with mark atwood at the = ietf meeting. he's coming down to the bay area for the mysql conference, = i hope to buy him a beer some evening and run a few proposals past him = wrt OAuth and it's use in OGP.

and. ack. i should probably have = mentioned this earlier. i got a lot of good feedback about the drafts we = published, and one of the things that's going into the next rev of the = auth draft is how to deal with transport authentication ( like when your = transport manages authentication for you like client side certs and HTTP = digest (*shudder*) ). eventually OpenID should go into a similar = section, but we feel there are still a few open issues with it's use. = declaring the solution to being "we just use XRI" and declaring victory = seems a little hasty, but it seems like there's enough interest to = warrant it's inclusion in any future charter / IDs / etc.

i = haven't heard anyone say they have serious problems with OpenID in = general. i mean... if someone was implying that OpenID kills puppies, i = missed it. that being said, XRI / XRDS and OpenID are not in universal = use, so it's unlikely a statement like "OGP will only ever use OpenID" = will ever pass the humm test. but the statement "OpenID and XRDS should = forever be banished from OGP" will also never pass the humm = test.

which is to say... if anyone's willing to do the work to = figure out how to wedge OpenID into OGP, i'm all for it. to be clear, in = this context, the word "work" means:

1. you work with other list = members requirements.
2. you produce a document describing how OpenID = or XRDS can be used in conjunction with the existing spec (though the = existing specs are cast in jello, not in stone, so there's some room to = modify them if we absolutely have to.)
3. producing code to = demonstrate it's use.. *cough*PyOGP*cough*

so.. to recap.. we = (LL) have made no statement about OpenID one way or another. so... don't = hold your breath waiting for us to deploy services that consume OpenID = id services. still, it's gaining in popularity, so we're not going to = ignore it, we want to make sure it's properly applied to the problem at = hand. ditto with OAuth. ditto with SAML 1.1 / Shib = 1.3.

-cheers
-meadhbh

On Apr 2, 2009, at 2:53 PM, = Christian Scholz wrote:

Jon Watte = schrieb:
Christian Scholz = wrote:
Another option would be to join = forces with the OAuth group at IETF and check on how we could add = identity to OAuth (there is discussion about that already). Eventually = this might be an easier choice and you could do authorization in one = step, at least for some centralized = services.
The first question is: does the = OAuth "callback" URL work in a VW sense? At a minimum, this means that a = VW needs to have a publicly available *incoming* URL for receiving = authentication tokens. For a VW behind a firewall, that's not = necessarily true. (Then again, OAuth doesn't work for an intranet web = site behind a firewall, either)

The redirect = setup is only one example of obtaining the OAuth token. You can do it = whatever way you want to (the new version of the spec also makes that = clearer as it starts with just the way you actually do authorized = requests and only explains in the second part the redirect = mechanism).

But if you look = at e.g. iMovie and how it uploads movies to YouTube you have an example = of how a desktop app can do it (although it's not using OAuth I think = but probably Google AuthSub but it's basically the = same).

Basically = instead of having a callback URL the client will simply wait until the = user has finished authorization in the web browser. The server then = might tell him to go back to the client and click "Continue". After that = the client will contact the server again and will try to exchange the = request token for an access token which only will work if the user = authorized it.

I am not sure = though I understand the question. You might also be talking about the = server being behind a firewall and not reachable by the client. But then = I guess you need some ports open anyway for the client to be able to = connect any way.

-- = Christian



-- 
COM.lounge GmbH
http://comlounge.net
Hanbrucher Strasse 33, 52064 = Aachen
Amtsgericht Aachen HRB = 15170
Gesch=E4ftsf=FChrer: Dr. = Ben Scheffler, Christian Scholz

email: info@comlounge.net
=
fon: = +49-241-4007300
fax: = +49-241-97900850

personal email: = cs@comlounge.net
personal blog: http://mrtopf.de/blog
<= blockquote type=3D"cite">personal podcasts: http://openweb-podcast.de, http://datawithoutborders.net

_______________________________________________
mmox mailing = list
mmox@ietf.org
https://www.ietf.org/m= ailman/listinfo/mmox

= --Apple-Mail-13-560049226-- From jwatte@gmail.com Thu Apr 2 16:11:08 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65DDB28C146 for ; Thu, 2 Apr 2009 16:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Alt1o8LhRHzb for ; Thu, 2 Apr 2009 16:11:07 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by core3.amsl.com (Postfix) with ESMTP id 92ABB28C142 for ; Thu, 2 Apr 2009 16:11:07 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id l35so427310waf.5 for ; Thu, 02 Apr 2009 16:12:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=0ajBoZ3ekWR+STS6nqJx/Mfu3M/fE5nrTS1SZzfyqPU=; b=NUJPjMfHOzgwRUis2sl53D0CuoFry/Njk4IyIgf5PtIWfo63hAx13wwEA6aGHR2qbc ou5r5fw58xuuV4A8Y1VIbiiLkLI7gtma0lPBQEPsAOucluzbx0awHGWgwg1oTQQvPE8a ZVaHlLIg/xCoZc8VKRN8ljpl56STgCeONUNto= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=we762VKtdCIfzoJyAyPfS7kkMko9CBSQn4TZG5b2IUhewotjHBJG2euxS72MTlZcNV guEzZm+g6LWEzpeNBM9JyDYn3VYxEOPcPV4lDzTNFKnNQGSADws/RXt2kBYEo97Pcq1F CADGdf8KZZgWIfB4WW3Kvsbv2oh202mtq7Fn4= Received: by 10.115.22.1 with SMTP id z1mr236568wai.202.1238713929425; Thu, 02 Apr 2009 16:12:09 -0700 (PDT) Received: from ?10.10.111.233? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id l31sm2765920rvb.9.2009.04.02.16.12.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 02 Apr 2009 16:12:09 -0700 (PDT) Message-ID: <49D54648.4020007@gmail.com> Date: Thu, 02 Apr 2009 16:12:08 -0700 From: Jon Watte User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Christian Scholz References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <49D40A06.7030708@gmail.com> <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> <49D4295C.2020502@gmail.com> <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> <49D4E5AF.2030301@gmail.com> <49D51A7D.8000104@comlounge.net> <62BFE5680C037E4DA0B0A08946C0933D7B6934A3@rrsmsx506.amr.corp.intel.com> <49D52DCD.2000806@comlounge.net> <49D531DA.4080006@gmail.com> <49D533EA.4010301@comlounge.net> In-Reply-To: <49D533EA.4010301@comlounge.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 23:11:08 -0000 Christian Scholz wrote: > The redirect setup is only one example of obtaining the OAuth token. > You can do it whatever way you want to (the new version of the spec > also makes that clearer as it starts with just the way you actually do > authorized requests and only explains in the second part the redirect > mechanism). > When I register as a service provider for an OAuth service, I have to register a callback URL. That seems pretty hard-coded into the actual implementation to me. That service provider won't work with a service that doesn't have a user-visible callbacl URL. > But if you look at e.g. iMovie and how it uploads movies to YouTube > you have an example of how a desktop app can do it (although it's not > using OAuth I think but probably Google AuthSub but it's basically the > same). > The problem is not the desktop app not being reachable; the problem is the service requesting authentication not being reachable from the authentication provider. > > I am not sure though I understand the question. You might also be > talking about the server being behind a firewall and not reachable by > the client. But then I guess you need some ports open anyway for the > client to be able to connect any way. The client can get to the service requesting authentication. The service can get to the authentication provider. The client can get to the authentication provider. The authentication provider can /not/ get to the service. Thus, any callback scheme between the services may fail. The current implementation of OAuth in the services I've seen uses this callback with a registered URL, so this is not something you can change by only changing the client, or only changing the requesting service AFAICT. Sincerely, jw From infinity@lindenlab.com Thu Apr 2 16:12:24 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 342B828C149 for ; Thu, 2 Apr 2009 16:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.216 X-Spam-Level: X-Spam-Status: No, score=-3.216 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_LOW=-1] 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 gISkTpiA4hDh for ; Thu, 2 Apr 2009 16:12:22 -0700 (PDT) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id D62A828C146 for ; Thu, 2 Apr 2009 16:12:22 -0700 (PDT) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 0A28C1414003; Thu, 2 Apr 2009 16:13:25 -0700 (PDT) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: Christian Scholz In-Reply-To: <49D52DCD.2000806@comlounge.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 2 Apr 2009 16:13:24 -0700 References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <49D40A06.7030708@gmail.com> <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> <49D4295C.2020502@gmail.com> <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> <49D4E5AF.2030301@gmail.com><49D51A7D.8000104@comlounge.net><62BFE5680C037E4DA0B0A08946C0933D7B6934A3@rrsmsx506.amr.corp.intel .com> <49D52DCD.2000806@comlounge.net> X-Mailer: Apple Mail (2.930.3) Cc: Jon Watte , "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 23:12:24 -0000 hmm... there was a lot of discussion about this a year and some ago. =20 ("this" being how to wedge OpenID into SL) i think it fell off =20 everyone's radar 'cause there were larger fish to fry. i was looking =20 in the goupies chat logs and logs from zero's office hours and sldev, =20= but for the life of me i can't find the discussions i was thinking =20 about. anyone else remember hashing over OpenID in the past? it might =20= be a good place to start. On Apr 2, 2009, at 2:27 PM, Christian Scholz wrote: > Hurliman, John schrieb: >> Thank you Christian, I think this is the right approach. Using >> partially defined blanket terms such as "Agent Domain" or "Region >> Domain" conjure up different ideas in everyone's head and also tend >> to imply an unnecessary aggregation of services. If we can clearly >> define the actual work items such as identity, authentication, >> authorization, asset storage, asset representation (content types and >> metadata), communication and contact lists, etc. we would likely find >> much more common ground between parties and could start partitioning >> the work into manageable sized chunks. > > Thanks! > > In fact we could actually start with thinking about identification/=20 > authentication right away and maybe taking OpenID and see how it =20 > might fit in a not web-based environment (read: VW client). > > Another option would be to join forces with the OAuth group at IETF =20= > and check on how we could add identity to OAuth (there is discussion =20= > about that already). Eventually this might be an easier choice and =20 > you could do authorization in one step, at least for some =20 > centralized services. > > We could start by fleshing out some more detailed use cases to see =20 > what is needed, what can be provided by existing standards and what =20= > might be missing and needs some inventing. > > I am just too tired to start right away ;-) > > -- Christian > > > >> John >>> -----Original Message----- From: mmox-bounces@ietf.org >>> [mailto:mmox-bounces@ietf.org] On Behalf Of Christian Scholz Sent: >>> Thursday, April 02, 2009 1:05 PM To: Jon Watte Cc: mmox@ietf.org =20 >>> Subject: Re: [mmox] OGP scalability concerns >>> Jon Watte schrieb: >>>> Meadhbh Hamrick (Infinity) wrote: >>>>> so maybe we might say "virtual world avatar interop" or >>>>> "virtual world event stream interop"? >>>>> but not say "virtual world interop" 'cause it's too vague? >>> I would say that in fact we have quite a few areas where =20 >>> interoperability is possible if we start to cut the problem space >>> into smaller chunks. >>> Here are some: >>> - Identification (who is this agent?) - Profiles (information about >>> the logged in user) - friends/contacts (probably most worlds have >>> this) - group memberships (not every world might have this) - >>> (instant) messaging - presence - Assets such as >>> textures/photos/sounds etc. >>> Now if you take those than we can discuss what interoperability >>> means for each of them. In fact there are many formats/protocols >>> already available: >>> - OpenID, InformationCards etc. for identification - OpenSocial >>> RESTful API or PortableContacts (the same protocol) for profile and >>> contacts (in a limited fashion at least) - XMPP or IRC (and other >>> proprietary formats) for instant messaging. Might also include >>> presence although maybe this needs to be extended. - SMTP for not >>> so instant messaging >>> So in fact for some areas interoperability would already be >>> possible. It would at least allow a user with an account on service >>> A to login to service B and maybe be able to match contacts, chat >>> with people on other services and so on. >>> And basically what is describes then is a simple social network. If >>> you add 3D services on top then you have your virtual world and >>> this is where it becomes complicated. >>> If you take the above elements you also have an Agent Domain. So in >>> fact it's nothing else than the social networking part where the =20 >>> Region domain would be those additional 3D services. >>> Of course the AD also does a bit more, like trust brokering. >>> The thing is though: Why group all this together into one big >>> chunk? It will be more likely in the future that you will have data >>> stored on several services: your profile might be on MySpace (or >>> one of many), you chat via IRC on freenode, you have photos on >>> flickr which you might want to use as textures. So IMHO it makes >>> sense to allow this to be split up into several services. The only >>> question is how to bind this together. >>> I already mentioned XRDS here once, which is basically a list of >>> type URI/service URI pairs. A user could describe via XRDS where >>> profile, friends list etc. is stored and the client or the >>> simulator could then go and fetch it. No big Agent Domain would be >>> needed and you also could support various services where client and >>> simulator could choose those they understand. >>> The only thing of course where it gets tricky is authorization =20 >>> brokering. You don't want your data public (at least not all of >>> it). OAuth might give you some means of authorizing third parties >>> to give out data on your behalf. But the problem is of course that >>> you'd need to authorize each service individually which is not user >>> friendly. >>> So here is where some thinking is actually needed: How can an =20 >>> authorization broker be implemented. I would prefer it be OAuth >>> based because libraries and understanding of OAuth is there (and of >>> course it's also at the IETF ;-). And maybe we come back here to >>> the original scalability problem of the AgentDomain but at least it >>> would be only one problem for the AD to solve (although the name >>> might be not correct anymore then because all the stuff related to >>> an agent would be spread across different services). >>> As for naming though: it would then be >>> - profile interop - contactlist interop - group interop - chat >>> interop >>> etc. >>> The question to the group would now be: Would it be worthwhile to >>> try to use all those existing specifications and just build a way >>> around them to bundle those things? IMHO the implementation >>> wouldn't be so hard to do. It would be an area though where it's >>> very mixed with where the web/social networks are going so it would >>> make sense to do this together with web folks. >>> -- Christian >>> -- COM.lounge GmbH http://comlounge.net Hanbrucher Strasse 33, >>> 52064 Aachen Amtsgericht Aachen HRB 15170 Gesch=E4ftsf=FChrer: Dr. = Ben >>> Scheffler, Christian Scholz >>> email: info@comlounge.net fon: +49-241-4007300 fax: >>> +49-241-97900850 >>> personal email: cs@comlounge.net personal blog: >>> http://mrtopf.de/blog personal podcasts: http://openweb-podcast.de, >>> http://datawithoutborders.net >>> _______________________________________________ mmox mailing list = mmox@ietf.org=20 >>> https://www.ietf.org/mailman/listinfo/mmox > > > --=20 > COM.lounge GmbH > http://comlounge.net > Hanbrucher Strasse 33, 52064 Aachen > Amtsgericht Aachen HRB 15170 > Gesch=E4ftsf=FChrer: Dr. Ben Scheffler, Christian Scholz > > email: info@comlounge.net > fon: +49-241-4007300 > fax: +49-241-97900850 > > personal email: cs@comlounge.net > personal blog: http://mrtopf.de/blog > personal podcasts: http://openweb-podcast.de, = http://datawithoutborders.net > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From charles.krinke@gmail.com Thu Apr 2 16:54:34 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 077753A6A39 for ; Thu, 2 Apr 2009 16:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.345 X-Spam-Level: X-Spam-Status: No, score=-2.345 tagged_above=-999 required=5 tests=[AWL=0.253, 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 A9P3C5cI0swm for ; Thu, 2 Apr 2009 16:54:33 -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 212B03A691B for ; Thu, 2 Apr 2009 16:54:32 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 5so1019359ywh.49 for ; Thu, 02 Apr 2009 16:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=uLsOOoQjuzBse4yqMm6ogLaQWSSZ7jYezd5UNqstPf0=; b=SUsdOeyuKxu7QyFo4ANIEs5qIR8irY/QOh8Dyx+e0gq4ujDP2ZZhnefSIzn/qyVNNz eofQU/hOIS6Z2SZRU6JGFoXNj8w/Ku+qbk0BX2iEcnJqBQC8L5wIY7aD2Gn8PH5WKI8g HIXab7sFk8DJh8Paket74wHWyMzaiL3oeH1p8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wvby8X29+HE7DvkWYxMPUxdiq2lnYoUAsbz9sXp9fseVK7hHOIq2ohKK0nMqDbUpWw ublVf5uBuCWC+pPg7+y7ehjQZuTj7UR6u+ubtPgiUwuhshG1vPt9oTQBeS2XUmjuUZtA 7xZJoopZyNv++R8qlMi1R87E4R9hQhQ1W2i0M= MIME-Version: 1.0 Received: by 10.100.216.12 with SMTP id o12mr1316852ang.39.1238716534220; Thu, 02 Apr 2009 16:55:34 -0700 (PDT) In-Reply-To: References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <49D40A06.7030708@gmail.com> <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> <49D4295C.2020502@gmail.com> <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> <49D4E5AF.2030301@gmail.com> <49D51A7D.8000104@comlounge.net> <49D52DCD.2000806@comlounge.net> Date: Thu, 2 Apr 2009 15:55:34 -0800 Message-ID: From: Charles Krinke To: "Meadhbh Hamrick (Infinity)" Content-Type: multipart/alternative; boundary=0016368e1f21ffea8804669b2a44 Cc: "mmox@ietf.org" , Jon Watte Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 23:54:34 -0000 --0016368e1f21ffea8804669b2a44 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I believe that thanks to the efforts of JHurliman and others, we have OpenID in the OpenSim server so we are ready to go. As long as JHurliman is hesitant on OGP, so am I personally, but we have MXP, HyperGrid interop running now and have been able to accept AgentDomain connections over OGP from the SecondLife BetaGrid. On the AgentDomain bit, as long as we can perceive a way that other grids can establish a connection *back* to a SecondLife grid with their own implementation of AgentDomain, UGAIM or OGS (OpenGridServices), I personally dont have a lot of objection other then that voiced by my respected peers. So, lets move forward. -- Charles Krinke OpenSim Core Developer OSGrid Director --0016368e1f21ffea8804669b2a44 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I believe that thanks to the efforts of JHurliman and others, we have OpenI= D in the OpenSim server so we are ready to go.

=C2=A0As long as JHur= liman is hesitant on OGP, so am I personally, but we have MXP, HyperGrid in= terop running now and have been able to accept AgentDomain connections over= OGP from the SecondLife BetaGrid.

On the AgentDomain bit, as long as we can perceive a way that other gri= ds can establish a connection *back* to a SecondLife grid with their own im= plementation of AgentDomain, UGAIM or OGS (OpenGridServices), I personally = dont have a lot of objection other then that voiced by my respected peers.<= br>
So, lets move forward.

--
Charles Krinke
Op= enSim Core Developer
OSGrid Director
--0016368e1f21ffea8804669b2a44-- From john.hurliman@intel.com Thu Apr 2 17:01:33 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 926F93A691C for ; Thu, 2 Apr 2009 17:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.301, 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 iKW09P5LTv-B for ; Thu, 2 Apr 2009 17:01:32 -0700 (PDT) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by core3.amsl.com (Postfix) with ESMTP id CC2503A684C for ; Thu, 2 Apr 2009 17:01:32 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 02 Apr 2009 16:53:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.39,316,1235980800"; d="scan'208";a="678346024" Received: from rrsmsx604.amr.corp.intel.com ([10.31.0.170]) by fmsmga001.fm.intel.com with ESMTP; 02 Apr 2009 17:06:17 -0700 Received: from rrsmsx002.amr.corp.intel.com (10.31.0.34) by rrsmsx604.amr.corp.intel.com (10.31.0.170) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 2 Apr 2009 18:02:34 -0600 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx002.amr.corp.intel.com ([10.31.0.34]) with mapi; Thu, 2 Apr 2009 18:02:34 -0600 From: "Hurliman, John" To: "mmox@ietf.org" Date: Thu, 2 Apr 2009 18:02:24 -0600 Thread-Topic: [mmox] OGP scalability concerns Thread-Index: Acmz4XwJnc/R3yv3S8KP1Rx1UNKnMwADL4HA Message-ID: <62BFE5680C037E4DA0B0A08946C0933D7B693676@rrsmsx506.amr.corp.intel.com> References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <49D40A06.7030708@gmail.com> <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> <49D4295C.2020502@gmail.com> <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> <49D4E5AF.2030301@gmail.com> <49D51A7D.8000104@comlounge.net> <62BFE5680C037E4DA0B0A08946C0933D7B6934A3@rrsmsx506.amr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {A37575B9-D66E-45F5-8564-B9DD62D9E26F} x-cr-hashedpuzzle: ApUP CYqP DO5q Du1e EZ2u EZ8D Fy0I GtWb HK9F HZs/ HdkX HxFD Hz/s IBAl KX5p KgrQ; 1; bQBtAG8AeABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {A37575B9-D66E-45F5-8564-B9DD62D9E26F}; agBvAGgAbgAuAGgAdQByAGwAaQBtAGEAbgBAAGkAbgB0AGUAbAAuAGMAbwBtAA==; Fri, 03 Apr 2009 00:02:24 GMT; UgBFADoAIABbAG0AbQBvAHgAXQAgAE8ARwBQACAAcwBjAGEAbABhAGIAaQBsAGkAdAB5ACAAYwBvAG4AYwBlAHIAbgBzAA== acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 00:01:33 -0000 > we also use the term "domain" in it's more traditional sense to imply > a bounds of authority. which is to say, we assume that all hosts and > services inside a domain are administered by the same entity. that > being said, there's no reason you can't have sub-domains, and there's > no reason that two services associated with "the" agent domain can't > be split across two administrative domains (like maybe yahoo or AOL > get in the business of moving virtual world IM messages but don't want > to deploy a world themselves.) it would require some coordination of > identity management issues, but i'm sure they're tractable. I understand this. If you are Linden Lab and you are already in the busines= s of running lots of independent services (content hosting, identity storag= e and authorization, instant messaging, inventory servers, simulators, etc)= then it makes sense to lump every service you want to provide under one tr= ust domain. Simulation can be a different domain so third party simulators = like OpenSim can run under a separate trust domain and optionally connect t= o the aggregate Linden Lab service cloud. Tada! You have OGP. It's a great = business model. Unless you are any company *except* Linden Lab and you want= to provide a service such as content hosting without becoming a full virtu= al world service provider. Using the current evolution of the web as historical evidence and assuming = that specialized service providers will be the norm, lumping together insta= nt messaging and content hosting under the same umbrella doesn't make any s= ense. This is why I'm in favor of starting from the ground up and defining = each use case and service endpoint, rather than trying to figure out clever= ways of shoehorning the "right" approach into Linden Lab's OGP. John From infinity@lindenlab.com Thu Apr 2 17:02:23 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E697E3A684C for ; Thu, 2 Apr 2009 17:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.355 X-Spam-Level: X-Spam-Status: No, score=-3.355 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 1iM6T4gR8TYA for ; Thu, 2 Apr 2009 17:02:23 -0700 (PDT) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 253033A6D5B for ; Thu, 2 Apr 2009 17:02:23 -0700 (PDT) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 2BCD21414005; Thu, 2 Apr 2009 17:03:25 -0700 (PDT) Message-Id: <3C59C4AA-CD4F-456D-83B5-35DC9DEAE4A7@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: Jason Giglio In-Reply-To: <49D4628B.9050207@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 2 Apr 2009 17:03:24 -0700 References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <49D4628B.9050207@gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 00:02:24 -0000 okay... if by "centralized manner" you're talking about something like the global PKI that PEM mandated then yes, let's not talk about that. however. i don't think we were ever talking about that. to date, the proposed use of X.509 has been to identify agent domains to region domains and region domains to each other. i don't think we're proposing the use of client certs for client applications to authenticate themselves to agent domains. or rather... no one's talking about REQUIRING it. as an option, it's perfectly fine, though a touch difficult to manage. trust DOES lose it's meaning when you dilute your CP and CPS to enable universal enrollment. and don't get me started about the weak semantics of key usage in virtually every implementation. however... remember that X.509 / PKIX are used to transport assertions about previously established trust relationships. it is possible for a relying party to map different cert chain trust points to different internal policies. for example, one could have a "high security" CA with a CPS that requires execution of a legally binding agreement and the establishment of a $50,000 bond. then there could be a "low security" CA that only required an email account and a credit card number. when protocol from a peer identified with a cert issued off the high security CA, the relying party (let's assume it's an asset server trying to decide whether a simulator is trusted.) the relying party might then decide... "okay.. it's the high security CA.. i know if he does something untrustworthy i can impound funds from the bond escrow account, so sure.. have some sensitive resources." but if the next peer is identified with a cert from the low security CA, the relying party might decide only to divulge full-perm assets with a creative commons license. so i guess what i'm saying is, we can't ignore the issue of trust, and while things are difficult, it is not outside the realm of possibility we could, in fact, establish a trust management system that communicates assertions about relationships independent of their interpretation. (i.e. - use X.509 in the way it's supposed to be used.) -cheers -meadhbh On Apr 2, 2009, at 12:00 AM, Jason Giglio wrote: > Meadhbh Hamrick (Infinity) wrote: >>>> * There will be millions of worlds in an Internet-scale metaverse, >>>> which makes the concept of interop through trust agreements far too >>>> narrow. Trust loses its meaning entirely when scaled to millions, >>>> becoming mere paperwork or "security theater". >> >> +1. what's your suggestion? > > > My suggestion is that it's not appropriate to talk about client > identity, trust, or authentication as a service to be provided in a > centralized manner. > > The rest of the Internet gets along just fine without it. Sure I can > get a CA to sign something that says I am who I am, but no one much > cares; the rest of the net has routed around the problem of client > identification. I'm not sure why we would need to tackle something so > fundamentally difficult here, when it's not really necessary. > > -Jason From infinity@lindenlab.com Thu Apr 2 17:16:54 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A2A13A684C for ; Thu, 2 Apr 2009 17:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.511 X-Spam-Level: X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 8wm-Q9TRz7yF for ; Thu, 2 Apr 2009 17:16:53 -0700 (PDT) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 95F5A3A6BB9 for ; Thu, 2 Apr 2009 17:16:52 -0700 (PDT) Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id CCD571414003; Thu, 2 Apr 2009 17:17:54 -0700 (PDT) Message-Id: <606A71E4-A150-4832-AFE7-C7947E728DCE@lindenlab.com> From: "Meadhbh Hamrick (Infinity)" To: "Hurliman, John" In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D7B693676@rrsmsx506.amr.corp.intel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 2 Apr 2009 17:17:54 -0700 References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <49D40A06.7030708@gmail.com> <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> <49D4295C.2020502@gmail.com> <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> <49D4E5AF.2030301@gmail.com> <49D51A7D.8000104@comlounge.net> <62BFE5680C037E4DA0B0A08946C0933D7B6934A3@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933D7B693676@rrsmsx506.amr.corp.intel.com> X-Mailer: Apple Mail (2.930.3) Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 00:16:54 -0000 i would argue that there _are_ in fact OpenSim operators who would want to connect to linden servers and consume linden services. we use URIs as caps and mandate consumers of these caps treat them as opaque web addresses explicitly because we want to support the use case where the host that responds to a seed cap request can provide a URI in a different administrative domain for other services.. um.. like.. i dunno.. like where your identity and presence is managed on a server distinct from the one that provides SIP/RTP voice services. i applaud your effort to shoehorn technologies into a codebase. we'll be over here trying to build a coherent set of services whose use semantics are conformable. -cheers -meadhbh On Apr 2, 2009, at 5:02 PM, Hurliman, John wrote: >> we also use the term "domain" in it's more traditional sense to imply >> a bounds of authority. which is to say, we assume that all hosts and >> services inside a domain are administered by the same entity. that >> being said, there's no reason you can't have sub-domains, and there's >> no reason that two services associated with "the" agent domain can't >> be split across two administrative domains (like maybe yahoo or AOL >> get in the business of moving virtual world IM messages but don't >> want >> to deploy a world themselves.) it would require some coordination of >> identity management issues, but i'm sure they're tractable. > > I understand this. If you are Linden Lab and you are already in the > business of running lots of independent services (content hosting, > identity storage and authorization, instant messaging, inventory > servers, simulators, etc) then it makes sense to lump every service > you want to provide under one trust domain. Simulation can be a > different domain so third party simulators like OpenSim can run > under a separate trust domain and optionally connect to the > aggregate Linden Lab service cloud. Tada! You have OGP. It's a great > business model. Unless you are any company *except* Linden Lab and > you want to provide a service such as content hosting without > becoming a full virtual world service provider. > > Using the current evolution of the web as historical evidence and > assuming that specialized service providers will be the norm, > lumping together instant messaging and content hosting under the > same umbrella doesn't make any sense. This is why I'm in favor of > starting from the ground up and defining each use case and service > endpoint, rather than trying to figure out clever ways of > shoehorning the "right" approach into Linden Lab's OGP. > > John > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox From charles.krinke@gmail.com Thu Apr 2 17:48:55 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA0473A6BED for ; Thu, 2 Apr 2009 17:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.091, 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 nY9m3q+7QDSJ for ; Thu, 2 Apr 2009 17:48:54 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by core3.amsl.com (Postfix) with ESMTP id 83E803A69BF for ; Thu, 2 Apr 2009 17:48:54 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so784806rvb.49 for ; Thu, 02 Apr 2009 17:49:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=IIjraTk/igo08Kesc4G7YDtFvgMbjLYXvU6Eg+Pdzts=; b=aCsF4g++/EOxqYW1+xq5scG/Qs4FltI/i01vV+Hg9G2zUa67AZJPyURQSISLHv/sYF b0GSbrbjGymO+WO9R46kp0/FrCcvlUluA3ePcrYhGriP1d8bP2HPo02KM2eyYgs+g44d ZZbMaDb4GqQeyaulg7RoiCtdfCM/sn+mQCOEU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=T9Md37gYoBLwVJCyorFBOgWtiMTNuxEaXBuMOz25jCxhRvFGCiRz6d/nvk9IAKXznb Fwf69zPONIxZXWDbbgy8PbLWvHJ4flG1T73GPIbGaRp+a6NZu4x/Fa4sDooUUwLlbAFI ZFZamzsR4piE5tDszC1qHyQvfLmrhfZE3y+2s= MIME-Version: 1.0 Received: by 10.114.174.2 with SMTP id w2mr271544wae.195.1238719796521; Thu, 02 Apr 2009 17:49:56 -0700 (PDT) In-Reply-To: <606A71E4-A150-4832-AFE7-C7947E728DCE@lindenlab.com> References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> <49D4295C.2020502@gmail.com> <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> <49D4E5AF.2030301@gmail.com> <49D51A7D.8000104@comlounge.net> <62BFE5680C037E4DA0B0A08946C0933D7B6934A3@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933D7B693676@rrsmsx506.amr.corp.intel.com> <606A71E4-A150-4832-AFE7-C7947E728DCE@lindenlab.com> Date: Thu, 2 Apr 2009 16:49:56 -0800 Message-ID: From: Charles Krinke To: "Meadhbh Hamrick (Infinity)" Content-Type: multipart/alternative; boundary=0016364571b072aae804669bed22 Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 00:48:55 -0000 --0016364571b072aae804669bed22 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Yes, I would concur. There are OpenSim adopters that do wish and are using OpenSim regions to connect to SecondLife using OGP and I applaud that use case and wish to see it continue. I have to admit that my personal bias came out a little bit. That personal bias is that my personal heart is also attached to the OSGrid project, which is a growing grid of regions that one day (I hope), there will exist some proper and negotiated way to teleport from OSGrid to a SecondLife grid. Whether or not that will happen is in the future and something yet to be negotiated, but I wear two hats. One of those hats is that of an OpenSim Core developer and the second hat is that of one of the Directors of OSGrid. I try *really* hard to be fair to all, so please pardon me if my OSGrid bias came out a little bit on the "symmetry" question of interop. Charles Krinke OpenSim Core Developer OSGrid Director On Thu, Apr 2, 2009 at 4:17 PM, Meadhbh Hamrick (Infinity) < infinity@lindenlab.com> wrote: > i would argue that there _are_ in fact OpenSim operators who would want to > connect to linden servers and consume linden services. > > we use URIs as caps and mandate consumers of these caps treat them as > opaque web addresses explicitly because we want to support the use case > where the host that responds to a seed cap request can provide a URI in a > different administrative domain for other services.. um.. like.. i dunno.. > like where your identity and presence is managed on a server distinct from > the one that provides SIP/RTP voice services. > > i applaud your effort to shoehorn technologies into a codebase. we'll be > over here trying to build a coherent set of services whose use semantics are > conformable. > > -cheers > -meadhbh > > On Apr 2, 2009, at 5:02 PM, Hurliman, John wrote: > > we also use the term "domain" in it's more traditional sense to imply >>> a bounds of authority. which is to say, we assume that all hosts and >>> services inside a domain are administered by the same entity. that >>> being said, there's no reason you can't have sub-domains, and there's >>> no reason that two services associated with "the" agent domain can't >>> be split across two administrative domains (like maybe yahoo or AOL >>> get in the business of moving virtual world IM messages but don't want >>> to deploy a world themselves.) it would require some coordination of >>> identity management issues, but i'm sure they're tractable. >>> >> >> I understand this. If you are Linden Lab and you are already in the >> business of running lots of independent services (content hosting, identity >> storage and authorization, instant messaging, inventory servers, simulators, >> etc) then it makes sense to lump every service you want to provide under one >> trust domain. Simulation can be a different domain so third party simulators >> like OpenSim can run under a separate trust domain and optionally connect to >> the aggregate Linden Lab service cloud. Tada! You have OGP. It's a great >> business model. Unless you are any company *except* Linden Lab and you want >> to provide a service such as content hosting without becoming a full virtual >> world service provider. >> >> Using the current evolution of the web as historical evidence and assuming >> that specialized service providers will be the norm, lumping together >> instant messaging and content hosting under the same umbrella doesn't make >> any sense. This is why I'm in favor of starting from the ground up and >> defining each use case and service endpoint, rather than trying to figure >> out clever ways of shoehorning the "right" approach into Linden Lab's OGP. >> >> John >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > -- Charles Krinke OpenSim Core Developer OSGrid Director --0016364571b072aae804669bed22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, I would concur. There are OpenSim adopters that do wish and are using = OpenSim regions to connect to SecondLife using OGP and I applaud that use c= ase and wish to see it continue.

I have to admit that my personal bi= as came out a little bit. That personal bias is that my personal heart is a= lso attached to the OSGrid project, which is a growing grid of regions that= one day (I hope), there will exist some proper and negotiated way to telep= ort from OSGrid to a SecondLife grid. Whether or not that will happen is in= the future and something yet to be negotiated, but I wear two hats.

One of those hats is that of an OpenSim Core developer and the second h= at is that of one of the Directors of OSGrid. I try *really* hard to be fai= r to all, so please pardon me if my OSGrid bias came out a little bit on th= e "symmetry" question of interop.

Charles Krinke
OpenSim Core Developer
OSGrid Director

On Thu, Apr 2, 2009 at 4:17 PM, Meadhbh Hamrick (Inf= inity) <infinity@lindenlab.com> wrote:
i would argue tha= t there _are_ in fact OpenSim operators who would want to connect to linden= servers and consume linden services.

we use URIs as caps and mandate consumers of these caps treat them as opaqu= e web addresses explicitly because we want to support the use case where th= e host that responds to a seed cap request can provide a URI in a different= administrative domain for other services.. um.. like.. i dunno.. like wher= e your identity and presence is managed on a server distinct from the one t= hat provides SIP/RTP voice services.

i applaud your effort to shoehorn technologies into a codebase. we'll b= e over here trying to build a coherent set of services whose use semantics = are conformable.

-cheers
-meadhbh


On Apr 2, 2009, at 5:02 PM, Hurliman, John wrote:

we also use the term "domain" in it's more traditional sense = to imply
a bounds of authority. which is to say, we assume that all hosts and
services inside a domain are administered by the same entity. that
being said, there's no reason you can't have sub-domains, and there= 's
no reason that two services associated with "the" agent domain ca= n't
be split across two administrative domains (like maybe yahoo or AOL
get in the business of moving virtual world IM messages but don't want<= br> to deploy a world themselves.) it would require some coordination of
identity management issues, but i'm sure they're tractable.

I understand this. If you are Linden Lab and you are already in the busines= s of running lots of independent services (content hosting, identity storag= e and authorization, instant messaging, inventory servers, simulators, etc)= then it makes sense to lump every service you want to provide under one tr= ust domain. Simulation can be a different domain so third party simulators = like OpenSim can run under a separate trust domain and optionally connect t= o the aggregate Linden Lab service cloud. Tada! You have OGP. It's a gr= eat business model. Unless you are any company *except* Linden Lab and you = want to provide a service such as content hosting without becoming a full v= irtual world service provider.

Using the current evolution of the web as historical evidence and assuming = that specialized service providers will be the norm, lumping together insta= nt messaging and content hosting under the same umbrella doesn't make a= ny sense. This is why I'm in favor of starting from the ground up and d= efining each use case and service endpoint, rather than trying to figure ou= t clever ways of shoehorning the "right" approach into Linden Lab= 's OGP.

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

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



--
Charles Kri= nke
OpenSim Core Developer
OSGrid Director
--0016364571b072aae804669bed22-- From jwatte@gmail.com Thu Apr 2 21:39:45 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 614663A6A17 for ; Thu, 2 Apr 2009 21:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 J3fzrp5bTsSA for ; Thu, 2 Apr 2009 21:39:44 -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 7C94E3A68F8 for ; Thu, 2 Apr 2009 21:39:44 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so856343rvb.49 for ; Thu, 02 Apr 2009 21:40:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=1A0LjZWOY+doLKfFMhbMV46u+DRSCJW+R6EWalIjVkg=; b=nM3jVUxNCADGE9+AMoDbDd6vsK+2G3Ve17L2PUvVMd//onCmVC35MzWUbeOAcJj5di g8udyaq6lU1nSMmf1tIPnOWClAD/kBxdwxZQwBAoPRkk16w7ek1E6a7Qy4sNTyDOTpgI J1v7Y/zfLDtH/cf0xMRaZ37VgccVHrD77MKT4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=G0KYJ668h+Z6iluxh1oNiVJGLd+6HNlF2dIEDKzYoMUkT3WMcZ9ZuSl04GNlKFxL0J HH7WSW1Im+tpeHvUp/PzVbv6Ifmxrafugz2bkv5vNs9dqwekH6QByY7gvXaPVkfcJgqA 9y5hIa7i7whFw5nzWsOQQt8tHZIR90tdxcBoY= Received: by 10.114.177.1 with SMTP id z1mr385723wae.68.1238733646678; Thu, 02 Apr 2009 21:40:46 -0700 (PDT) Received: from ?192.168.1.101? (svn.mindcontrol.org [69.17.45.136]) by mx.google.com with ESMTPS id j34sm1811754waf.27.2009.04.02.21.40.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 02 Apr 2009 21:40:46 -0700 (PDT) Message-ID: <49D5934D.6020406@gmail.com> Date: Thu, 02 Apr 2009 21:40:45 -0700 From: Jon Watte User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <49D4628B.9050207@gmail.com> <3C59C4AA-CD4F-456D-83B5-35DC9DEAE4A7@lindenlab.com> In-Reply-To: <3C59C4AA-CD4F-456D-83B5-35DC9DEAE4A7@lindenlab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 04:39:45 -0000 Meadhbh Hamrick (Infinity) wrote: > to date, the proposed use of X.509 has been to identify agent domains > to region domains and region domains to each other. i don't think > we're proposing the use of client certs for client applications to > authenticate themselves to agent domains. or rather... no one's > talking about REQUIRING it. as an option, it's perfectly fine, though > a touch difficult to manage. I think that authentication comes in two flavors: Authenticating users, and authenticating entities that authenticate users. If you will, OAuth authenticates users, but how do you know who the OAuth provider is? That may be a separately established trust, that may be negotiated, or may be untrusted-but-traceable. i would argue that there _are_ in fact OpenSim operators who would want to connect to linden servers and consume linden services. I agree. However, there may also be operators who want to consume some Linden services, and some other services. Thus, it makes sense in that context, like John claims, to un-bundle each service. If the protocol allows you to discover multiple services in one go, and even authenticate for multiple services in one go, that's probably fine (and maybe even desired), but there shouldn't be anything in the protocol that requires all the services to come in one bundle. Even if some providers can provide them all in a bundle, the user probably will want to un-bundle them in certain cases. Sincerely, jw From cs@comlounge.net Fri Apr 3 02:10:50 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C60E3A68C7 for ; Fri, 3 Apr 2009 02:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_36=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 HtKCv8qch6gj for ; Fri, 3 Apr 2009 02:10:49 -0700 (PDT) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id BB76C3A69DB for ; Fri, 3 Apr 2009 02:10:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 7BC926F4012; Fri, 3 Apr 2009 11:11:50 +0200 (CEST) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sbq7x02Ei9J1; Fri, 3 Apr 2009 11:11:41 +0200 (CEST) Received: from [192.168.2.101] (pC19EAD7C.dip.t-dialin.net [193.158.173.124]) by post.comlounge.net (Postfix) with ESMTP id C7B661CE0039; Fri, 3 Apr 2009 11:11:40 +0200 (CEST) Message-ID: <49D5D2CC.6010105@comlounge.net> Date: Fri, 03 Apr 2009 11:11:40 +0200 From: Christian Scholz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <49D40A06.7030708@gmail.com> <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> <49D4295C.2020502@gmail.com> <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> <49D4E5AF.2030301@gmail.com><49D51A7D.8000104@comlounge.net><62BFE5680C037E4DA0B0A08946C0933D7B6934A3@rrsmsx506.amr.corp.intel .com><49D52DCD.2000806@comlounge.net> <49D531DA.4080006@gmail.com> <49D533EA.4010301@comlounge.net> <4DF1C9A3-6170-4448-95DD-A3C72901A53A@lindenlab.com> In-Reply-To: <4DF1C9A3-6170-4448-95DD-A3C72901A53A@lindenlab.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "mmox@ietf.org" , Jon Watte Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 09:10:50 -0000 Hi! Meadhbh Hamrick (Infinity) schrieb: > yup. for what it's worth, i had several good chats with mark atwood at > the ietf meeting. he's coming down to the bay area for the mysql > conference, i hope to buy him a beer some evening and run a few > proposals past him wrt OAuth and it's use in OGP. I would actually like to learn more about those conversations you had at the meeting ;-) And I am still looking forward to hear more about the ProtectServe stuff they are working on. > and. ack. i should probably have mentioned this earlier. i got a lot of > good feedback about the drafts we published, and one of the things > that's going into the next rev of the auth draft is how to deal with > transport authentication ( like when your transport manages > authentication for you like client side certs and HTTP digest > (*shudder*) ). eventually OpenID should go into a similar section, but > we feel there are still a few open issues with it's use. declaring the > solution to being "we just use XRI" and declaring victory seems a little > hasty, but it seems like there's enough interest to warrant it's > inclusion in any future charter / IDs / etc. > > i haven't heard anyone say they have serious problems with OpenID in > general. i mean... if someone was implying that OpenID kills puppies, i > missed it. that being said, XRI / XRDS and OpenID are not in universal > use, so it's unlikely a statement like "OGP will only ever use OpenID" > will ever pass the humm test. but the statement "OpenID and XRDS should > forever be banished from OGP" will also never pass the humm test. I personally did not want to imply that OpenID should be the only thing to support. We always talked about some pluggable mechanism for authentication and I still think that's the way to go. As for a service catalogue it could simply list several authentication methods and the other side can select the best suited one. > which is to say... if anyone's willing to do the work to figure out how > to wedge OpenID into OGP, i'm all for it. to be clear, in this context, > the word "work" means: > > 1. you work with other list members requirements. > 2. you produce a document describing how OpenID or XRDS can be used in > conjunction with the existing spec (though the existing specs are cast > in jello, not in stone, so there's some room to modify them if we > absolutely have to.) > 3. producing code to demonstrate it's use.. *cough*PyOGP*cough* I am certainly willing to work on use cases, requirements and discussing a solution but my personal priority would be on the general social networking case, not OGP (which might mean of course that this work might also be done outside this group if there is no interest in that). I am also not sure how to mix it with OGP. OAuth would be most likely a replacement for caps, wouldn't it? So maybe it would be then fitting into the spec. I am with John here though and IMHO the Agent Domain really should be split into it's individual services which all are usable independantly of each other. > so.. to recap.. we (LL) have made no statement about OpenID one way or > another. so... don't hold your breath waiting for us to deploy services > that consume OpenID id services. still, it's gaining in popularity, so > we're not going to ignore it, we want to make sure it's properly applied > to the problem at hand. ditto with OAuth. ditto with SAML 1.1 / Shib 1.3. I think we all want to have it properly applied :-) I think on this list we are right now also more struggling at defining "the problem at hand" ;-) -- Christian > On Apr 2, 2009, at 2:53 PM, Christian Scholz wrote: > >> Jon Watte schrieb: >>> Christian Scholz wrote: >>>> Another option would be to join forces with the OAuth group at IETF >>>> and check on how we could add identity to OAuth (there is discussion >>>> about that already). Eventually this might be an easier choice and >>>> you could do authorization in one step, at least for some >>>> centralized services. >>> The first question is: does the OAuth "callback" URL work in a VW >>> sense? At a minimum, this means that a VW needs to have a publicly >>> available *incoming* URL for receiving authentication tokens. For a >>> VW behind a firewall, that's not necessarily true. (Then again, OAuth >>> doesn't work for an intranet web site behind a firewall, either) >> >> The redirect setup is only one example of obtaining the OAuth token. >> You can do it whatever way you want to (the new version of the spec >> also makes that clearer as it starts with just the way you actually do >> authorized requests and only explains in the second part the redirect >> mechanism). >> >> But if you look at e.g. iMovie and how it uploads movies to YouTube >> you have an example of how a desktop app can do it (although it's not >> using OAuth I think but probably Google AuthSub but it's basically the >> same). >> >> Basically instead of having a callback URL the client will simply wait >> until the user has finished authorization in the web browser. The >> server then might tell him to go back to the client and click >> "Continue". After that the client will contact the server again and >> will try to exchange the request token for an access token which only >> will work if the user authorized it. >> >> I am not sure though I understand the question. You might also be >> talking about the server being behind a firewall and not reachable by >> the client. But then I guess you need some ports open anyway for the >> client to be able to connect any way. >> >> -- Christian >> >> >> >> -- >> COM.lounge GmbH >> http://comlounge.net >> Hanbrucher Strasse 33, 52064 Aachen >> Amtsgericht Aachen HRB 15170 >> Geschäftsführer: Dr. Ben Scheffler, Christian Scholz >> >> email: info@comlounge.net >> fon: +49-241-4007300 >> fax: +49-241-97900850 >> >> personal email: cs@comlounge.net >> personal blog: http://mrtopf.de/blog >> personal podcasts: http://openweb-podcast.de, >> http://datawithoutborders.net >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > -- COM.lounge GmbH http://comlounge.net Hanbrucher Strasse 33, 52064 Aachen Amtsgericht Aachen HRB 15170 Geschäftsführer: Dr. Ben Scheffler, Christian Scholz email: info@comlounge.net fon: +49-241-4007300 fax: +49-241-97900850 personal email: cs@comlounge.net personal blog: http://mrtopf.de/blog personal podcasts: http://openweb-podcast.de, http://datawithoutborders.net From cs@comlounge.net Fri Apr 3 02:15:27 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7041E3A69DB for ; Fri, 3 Apr 2009 02:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.139 X-Spam-Level: X-Spam-Status: No, score=-2.139 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, J_CHICKENPOX_36=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 lcu+gu5z2Er1 for ; Fri, 3 Apr 2009 02:15:26 -0700 (PDT) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id A9CF53A68C7 for ; Fri, 3 Apr 2009 02:15:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id BDE186F4012; Fri, 3 Apr 2009 11:16:27 +0200 (CEST) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUW7ahPkdQlv; Fri, 3 Apr 2009 11:16:25 +0200 (CEST) Received: from [192.168.2.101] (pC19EAD7C.dip.t-dialin.net [193.158.173.124]) by post.comlounge.net (Postfix) with ESMTP id AFAF61CE0039; Fri, 3 Apr 2009 11:16:24 +0200 (CEST) Message-ID: <49D5D3EA.1070304@comlounge.net> Date: Fri, 03 Apr 2009 11:16:26 +0200 From: Christian Scholz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Meadhbh Hamrick (Infinity)" References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <49D40A06.7030708@gmail.com> <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> <49D4295C.2020502@gmail.com> <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> <49D4E5AF.2030301@gmail.com><49D51A7D.8000104@comlounge.net><62BFE5680C037E4DA0B0A08946C0933D7B6934A3@rrsmsx506.amr.corp.intel .com> <49D52DCD.2000806@comlounge.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Jon Watte , "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 09:15:27 -0000 Meadhbh Hamrick (Infinity) schrieb: > hmm... there was a lot of discussion about this a year and some ago. > ("this" being how to wedge OpenID into SL) i think it fell off > everyone's radar 'cause there were larger fish to fry. i was looking in > the goupies chat logs and logs from zero's office hours and sldev, but > for the life of me i can't find the discussions i was thinking about. > anyone else remember hashing over OpenID in the past? it might be a good > place to start. I at least cannot remember a very specific discussion about it. I only remember you saying that it was at LL internally and there have been some concerns about it. Those never get published though (or I missed it). So it would be good to know what these concerns might be. Then again of course there are many issues with OpenID which are also known to the OpenID community, mainly regarding usability and phishing. So I would assume that these issues also apply to a use in virtual worlds. But eventually they will be solved. It probably would be good though to feed problems related to our space back to the community and work with them to find solutions. -- Christian > > On Apr 2, 2009, at 2:27 PM, Christian Scholz wrote: > >> Hurliman, John schrieb: >>> Thank you Christian, I think this is the right approach. Using >>> partially defined blanket terms such as "Agent Domain" or "Region >>> Domain" conjure up different ideas in everyone's head and also tend >>> to imply an unnecessary aggregation of services. If we can clearly >>> define the actual work items such as identity, authentication, >>> authorization, asset storage, asset representation (content types and >>> metadata), communication and contact lists, etc. we would likely find >>> much more common ground between parties and could start partitioning >>> the work into manageable sized chunks. >> >> Thanks! >> >> In fact we could actually start with thinking about >> identification/authentication right away and maybe taking OpenID and >> see how it might fit in a not web-based environment (read: VW client). >> >> Another option would be to join forces with the OAuth group at IETF >> and check on how we could add identity to OAuth (there is discussion >> about that already). Eventually this might be an easier choice and you >> could do authorization in one step, at least for some centralized >> services. >> >> We could start by fleshing out some more detailed use cases to see >> what is needed, what can be provided by existing standards and what >> might be missing and needs some inventing. >> >> I am just too tired to start right away ;-) >> >> -- Christian >> >> >> >>> John >>>> -----Original Message----- From: mmox-bounces@ietf.org >>>> [mailto:mmox-bounces@ietf.org] On Behalf Of Christian Scholz Sent: >>>> Thursday, April 02, 2009 1:05 PM To: Jon Watte Cc: mmox@ietf.org >>>> Subject: Re: [mmox] OGP scalability concerns >>>> Jon Watte schrieb: >>>>> Meadhbh Hamrick (Infinity) wrote: >>>>>> so maybe we might say "virtual world avatar interop" or >>>>>> "virtual world event stream interop"? >>>>>> but not say "virtual world interop" 'cause it's too vague? >>>> I would say that in fact we have quite a few areas where >>>> interoperability is possible if we start to cut the problem space >>>> into smaller chunks. >>>> Here are some: >>>> - Identification (who is this agent?) - Profiles (information about >>>> the logged in user) - friends/contacts (probably most worlds have >>>> this) - group memberships (not every world might have this) - >>>> (instant) messaging - presence - Assets such as >>>> textures/photos/sounds etc. >>>> Now if you take those than we can discuss what interoperability >>>> means for each of them. In fact there are many formats/protocols >>>> already available: >>>> - OpenID, InformationCards etc. for identification - OpenSocial >>>> RESTful API or PortableContacts (the same protocol) for profile and >>>> contacts (in a limited fashion at least) - XMPP or IRC (and other >>>> proprietary formats) for instant messaging. Might also include >>>> presence although maybe this needs to be extended. - SMTP for not >>>> so instant messaging >>>> So in fact for some areas interoperability would already be >>>> possible. It would at least allow a user with an account on service >>>> A to login to service B and maybe be able to match contacts, chat >>>> with people on other services and so on. >>>> And basically what is describes then is a simple social network. If >>>> you add 3D services on top then you have your virtual world and >>>> this is where it becomes complicated. >>>> If you take the above elements you also have an Agent Domain. So in >>>> fact it's nothing else than the social networking part where the >>>> Region domain would be those additional 3D services. >>>> Of course the AD also does a bit more, like trust brokering. >>>> The thing is though: Why group all this together into one big >>>> chunk? It will be more likely in the future that you will have data >>>> stored on several services: your profile might be on MySpace (or >>>> one of many), you chat via IRC on freenode, you have photos on >>>> flickr which you might want to use as textures. So IMHO it makes >>>> sense to allow this to be split up into several services. The only >>>> question is how to bind this together. >>>> I already mentioned XRDS here once, which is basically a list of >>>> type URI/service URI pairs. A user could describe via XRDS where >>>> profile, friends list etc. is stored and the client or the >>>> simulator could then go and fetch it. No big Agent Domain would be >>>> needed and you also could support various services where client and >>>> simulator could choose those they understand. >>>> The only thing of course where it gets tricky is authorization >>>> brokering. You don't want your data public (at least not all of >>>> it). OAuth might give you some means of authorizing third parties >>>> to give out data on your behalf. But the problem is of course that >>>> you'd need to authorize each service individually which is not user >>>> friendly. >>>> So here is where some thinking is actually needed: How can an >>>> authorization broker be implemented. I would prefer it be OAuth >>>> based because libraries and understanding of OAuth is there (and of >>>> course it's also at the IETF ;-). And maybe we come back here to >>>> the original scalability problem of the AgentDomain but at least it >>>> would be only one problem for the AD to solve (although the name >>>> might be not correct anymore then because all the stuff related to >>>> an agent would be spread across different services). >>>> As for naming though: it would then be >>>> - profile interop - contactlist interop - group interop - chat >>>> interop >>>> etc. >>>> The question to the group would now be: Would it be worthwhile to >>>> try to use all those existing specifications and just build a way >>>> around them to bundle those things? IMHO the implementation >>>> wouldn't be so hard to do. It would be an area though where it's >>>> very mixed with where the web/social networks are going so it would >>>> make sense to do this together with web folks. >>>> -- Christian >>>> -- COM.lounge GmbH http://comlounge.net Hanbrucher Strasse 33, >>>> 52064 Aachen Amtsgericht Aachen HRB 15170 Geschäftsführer: Dr. Ben >>>> Scheffler, Christian Scholz >>>> email: info@comlounge.net fon: +49-241-4007300 fax: >>>> +49-241-97900850 >>>> personal email: cs@comlounge.net personal blog: >>>> http://mrtopf.de/blog personal podcasts: http://openweb-podcast.de, >>>> http://datawithoutborders.net >>>> _______________________________________________ mmox mailing list >>>> mmox@ietf.org https://www.ietf.org/mailman/listinfo/mmox >> >> >> -- >> COM.lounge GmbH >> http://comlounge.net >> Hanbrucher Strasse 33, 52064 Aachen >> Amtsgericht Aachen HRB 15170 >> Geschäftsführer: Dr. Ben Scheffler, Christian Scholz >> >> email: info@comlounge.net >> fon: +49-241-4007300 >> fax: +49-241-97900850 >> >> personal email: cs@comlounge.net >> personal blog: http://mrtopf.de/blog >> personal podcasts: http://openweb-podcast.de, >> http://datawithoutborders.net >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox > -- COM.lounge GmbH http://comlounge.net Hanbrucher Strasse 33, 52064 Aachen Amtsgericht Aachen HRB 15170 Geschäftsführer: Dr. Ben Scheffler, Christian Scholz email: info@comlounge.net fon: +49-241-4007300 fax: +49-241-97900850 personal email: cs@comlounge.net personal blog: http://mrtopf.de/blog personal podcasts: http://openweb-podcast.de, http://datawithoutborders.net From cs@comlounge.net Fri Apr 3 02:23:16 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18CC228C13F for ; Fri, 3 Apr 2009 02:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.129 X-Spam-Level: X-Spam-Status: No, score=-2.129 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, J_CHICKENPOX_36=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 aRtpIktNL2t7 for ; Fri, 3 Apr 2009 02:23:15 -0700 (PDT) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id A7C5B28C134 for ; Fri, 3 Apr 2009 02:23:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id BE7881CE024D; Fri, 3 Apr 2009 11:24:02 +0200 (CEST) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGHNA83dZC1c; Fri, 3 Apr 2009 11:24:01 +0200 (CEST) Received: from [192.168.2.101] (pC19EAD7C.dip.t-dialin.net [193.158.173.124]) by post.comlounge.net (Postfix) with ESMTP id 759161CE0039; Fri, 3 Apr 2009 11:24:01 +0200 (CEST) Message-ID: <49D5D5B2.7030408@comlounge.net> Date: Fri, 03 Apr 2009 11:24:02 +0200 From: Christian Scholz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Hurliman, John" References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <49D40A06.7030708@gmail.com> <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> <49D4295C.2020502@gmail.com> <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> <49D4E5AF.2030301@gmail.com> <49D51A7D.8000104@comlounge.net> <62BFE5680C037E4DA0B0A08946C0933D7B6934A3@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933D7B693676@rrsmsx506.amr.corp.intel.com> In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D7B693676@rrsmsx506.amr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 09:23:16 -0000 Hurliman, John schrieb: >> we also use the term "domain" in it's more traditional sense to >> imply a bounds of authority. which is to say, we assume that all >> hosts and services inside a domain are administered by the same >> entity. that being said, there's no reason you can't have >> sub-domains, and there's no reason that two services associated >> with "the" agent domain can't be split across two administrative >> domains (like maybe yahoo or AOL get in the business of moving >> virtual world IM messages but don't want to deploy a world >> themselves.) it would require some coordination of identity >> management issues, but i'm sure they're tractable. > > I understand this. If you are Linden Lab and you are already in the > business of running lots of independent services (content hosting, > identity storage and authorization, instant messaging, inventory > servers, simulators, etc) then it makes sense to lump every service > you want to provide under one trust domain. Simulation can be a > different domain so third party simulators like OpenSim can run under > a separate trust domain and optionally connect to the aggregate > Linden Lab service cloud. Tada! You have OGP. It's a great business > model. Unless you are any company *except* Linden Lab and you want to > provide a service such as content hosting without becoming a full > virtual world service provider. It also reminds me of Facebook and Facebook connect where you also only get all or nothing. Moreover FB also defines who actually has access to _your_ data (e.g. Google has not). Nevertheless other players such as MySpace or Yahoo (and others) are becoming more open in a per-service level, e.g. providing OAuth based access to profile or friends data. What's missing there is still some way to list all of your services together and to find out which services a site provides. But there is work going on to solve these problems. I guess a good resource is Eran's blog (which I also should monitor more closely as a lot has happened there since I last looked, namely thoughts about delegated authorization as we might need it and XRD vs. XRDS): http://www.hueniverse.com > Using the current evolution of the web as historical evidence and > assuming that specialized service providers will be the norm, lumping > together instant messaging and content hosting under the same > umbrella doesn't make any sense. This is why I'm in favor of starting > from the ground up and defining each use case and service endpoint, > rather than trying to figure out clever ways of shoehorning the > "right" approach into Linden Lab's OGP. +1 -- Christian -- COM.lounge GmbH http://comlounge.net Hanbrucher Strasse 33, 52064 Aachen Amtsgericht Aachen HRB 15170 Geschäftsführer: Dr. Ben Scheffler, Christian Scholz email: info@comlounge.net fon: +49-241-4007300 fax: +49-241-97900850 personal email: cs@comlounge.net personal blog: http://mrtopf.de/blog personal podcasts: http://openweb-podcast.de, http://datawithoutborders.net From morgaine.dinova@googlemail.com Fri Apr 3 03:57:24 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ADF53A6B65 for ; Fri, 3 Apr 2009 03:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[AWL=0.090, 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 xl-drmiQHS0I for ; Fri, 3 Apr 2009 03:57:23 -0700 (PDT) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id 33A853A68C7 for ; Fri, 3 Apr 2009 03:57:22 -0700 (PDT) Received: by ewy9 with SMTP id 9so930361ewy.37 for ; Fri, 03 Apr 2009 03:58:24 -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=K+mBn5S+QeQ1F081KZ1qm9f5YZElbFilbjzCMXTbm5M=; b=aru6IoGYJqgL7DdTuZdADoeyFBk/o1fceG3FdSL882gYzGQnC2/QgdqVyTqyzrJ6oQ MznETvCG6Z7s5Mdo5bMel9iO0fVKeQYkVS+lTs3LnIA+R9i2O6x67dJOXkjBdbzuulps HJg37Q5QhrUmreQBOMds5g0LSNHuzjrhge03w= 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=LLhn/LZqzhZjaQ4c6UT1f7KmAnIOyWGbB3HZdD/ppI7ujCYHD8IvvI3DRdv2GafkqP zFoABSBYZHWVL/tag7nlZr4xEGI2dtOoJTxRR4aL9Q5Dh2fkTBl5hUIA/gwVQjyDqe4+ Y/1KECNQ/lsKVpS9voIQS0HmUbFIp5D89W8Ag= MIME-Version: 1.0 Received: by 10.216.26.80 with SMTP id b58mr368345wea.35.1238756304563; Fri, 03 Apr 2009 03:58:24 -0700 (PDT) In-Reply-To: <49D5D5B2.7030408@comlounge.net> References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> <49D4295C.2020502@gmail.com> <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> <49D4E5AF.2030301@gmail.com> <49D51A7D.8000104@comlounge.net> <62BFE5680C037E4DA0B0A08946C0933D7B6934A3@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933D7B693676@rrsmsx506.amr.corp.intel.com> <49D5D5B2.7030408@comlounge.net> Date: Fri, 3 Apr 2009 11:58:24 +0100 Message-ID: From: Morgaine To: Christian Scholz Content-Type: multipart/alternative; boundary=001485f423dc7f2f640466a46dd2 Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 10:57:24 -0000 --001485f423dc7f2f640466a46dd2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit John and Christian together have nailed a great candidate for the first step in the process of interoperation, I believe. Such initial unauthenticated service discovery would provide the opportunity for choice that leads to decoupling of services, whereas asking a bundling-prone VW provider for options is predestined to offer you very little real choice. On Fri, Apr 3, 2009 at 10:24 AM, Christian Scholz wrote: Hurliman, John schrieb: > >> I understand this. If you are Linden Lab and you are already in the >> business of running lots of independent services (content hosting, >> identity storage and authorization, instant messaging, inventory >> servers, simulators, etc) then it makes sense to lump every service >> you want to provide under one trust domain. Simulation can be a >> different domain so third party simulators like OpenSim can run under a >> separate trust domain and optionally connect to the aggregate Linden Lab >> service cloud. Tada! You have OGP. It's a great business model. Unless you >> are any company *except* Linden Lab and you want to provide a service such >> as content hosting without becoming a full virtual world service provider. >> > > It also reminds me of Facebook and Facebook connect where you also only get > all or nothing. Moreover FB also defines who actually has access to _your_ > data (e.g. Google has not). Nevertheless other players such as MySpace or > Yahoo (and others) are becoming more open in a per-service level, e.g. > providing OAuth based access to profile or friends data. > > What's missing there is still some way to list all of your services > together and to find out which services a site provides. But there is work > going on to solve these problems. I guess a good resource is Eran's blog > (which I also should monitor more closely as a lot has happened there since > I last looked, namely thoughts about delegated authorization as we might > need it and XRD vs. XRDS): > > > Those really are excellent points. Morgaine. --001485f423dc7f2f640466a46dd2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable John and Christian together have nailed a great candidate for the first ste= p in the process of interoperation, I believe.=A0 Such initial unauthentica= ted service discovery would provide the opportunity for choice that leads t= o decoupling of services, whereas asking a bundling-prone VW provider for o= ptions is predestined to offer you very little real choice.

On Fri, Apr 3, 2009 at 10:24 AM, Christian S= cholz <cs@comloung= e.net> wrote:

Hurliman, John schrieb:

I understand this. If you are Linden Lab and you are already in the
business of running lots of independent services (content hosting,
identity storage and authorization, instant messaging, inventory
servers, simulators, etc) then it makes sense to lump every service
you want to provide under one trust domain. Simulation can be a
different domain so third party simulators like OpenSim can run under a sep= arate trust domain and optionally connect to the aggregate Linden Lab servi= ce cloud. Tada! You have OGP. It's a great business model.=A0 Unless yo= u are any company *except* Linden Lab and you want to provide a service suc= h as content hosting without becoming a full virtual world service provider= .

It also reminds me of Facebook and Facebook connect where you also only get= all or nothing. Moreover FB also defines who actually has access to _your_= data (e.g. Google has not). Nevertheless other players such as MySpace or = Yahoo (and others) are becoming more open in a per-service level, e.g. prov= iding OAuth based access to profile or friends data.

What's missing there is still some way to list all of your services tog= ether and to find out which services a site provides. But there is work goi= ng on to solve these problems. I guess a good resource is Eran's blog (= which I also should monitor more closely as a lot has happened there since = I last looked, namely thoughts about delegated authorization as we might ne= ed it and XRD vs. XRDS):

=A0
Those really are excellent points.


Morgaine.


--001485f423dc7f2f640466a46dd2-- From charles.krinke@gmail.com Fri Apr 3 06:57:00 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 510423A6BFF for ; Fri, 3 Apr 2009 06:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.225, 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 iYizl7q8Lc7H for ; Fri, 3 Apr 2009 06:56:59 -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 58A6A3A6B92 for ; Fri, 3 Apr 2009 06:56:59 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so1341726yxm.49 for ; Fri, 03 Apr 2009 06:58:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=V0b2x5ONzjykyOjGoCDyXvYv1fcysGQ1S6e6mNLbqQU=; b=f6A3Jo1cQkEegOrJzdOTPgup1/OMAaFaAJR1rg+aIk4yQ4YSRkJ5rDx3tZW/Yi8CU7 UirVc8W7+Xu8fHJsf2yPWcMPT/cvQLQTnKOGMA5tPNaaNZfr0ra0NWaqyaaQPSTFTHFt FR8bdbiCOaDT85x6vm2HXXeyNJIRT21TBZsfc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jmklxB4wM7nbe/tSNVsWpXpc/90zUt0Yxe1Akm1fyoahiNKuAdLgf57NxhiAV2vq8p JfPECw6KKDTXL+YxB4D+LIyajtGwSHHGVFY9Rd1NOUZvThPovXsYFdMfaQcw6VgZbTYJ 3purch5LqmQDJr7DzF7RbSxoXCNTNWdZcyhU0= MIME-Version: 1.0 Received: by 10.100.120.19 with SMTP id s19mr1480271anc.12.1238767081222; Fri, 03 Apr 2009 06:58:01 -0700 (PDT) In-Reply-To: References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <49D4295C.2020502@gmail.com> <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> <49D4E5AF.2030301@gmail.com> <49D51A7D.8000104@comlounge.net> <62BFE5680C037E4DA0B0A08946C0933D7B6934A3@rrsmsx506.amr.corp.intel.com> <62BFE5680C037E4DA0B0A08946C0933D7B693676@rrsmsx506.amr.corp.intel.com> <49D5D5B2.7030408@comlounge.net> Date: Fri, 3 Apr 2009 05:58:01 -0800 Message-ID: From: Charles Krinke To: Morgaine Content-Type: multipart/alternative; boundary=0016e642d6d4d5f3570466a6ef33 Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 13:57:00 -0000 --0016e642d6d4d5f3570466a6ef33 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit I commend you all for finding a way to move forward and authentication is certainly an important one, but more importantly, working together is the key. To the extent we can have a dialog and express our personal opinions in "soft" manner and do few if any 'it must be my way or the highway", then we can perhaps get past talking "at" each other and closer to talking "to" each other. -- Charles Krinke OpenSim Core Developer OSGrid Director --0016e642d6d4d5f3570466a6ef33 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I commend you all for finding a way to move forward and authentication is c= ertainly an important one, but more importantly, working together is the ke= y.

To the extent we can have a dialog and express our personal opini= ons in "soft" manner and do few if any 'it must be my way or = the highway", then we can perhaps get past talking "at" each= other and closer to talking "to" each other.

--
Charles Krinke
OpenSim Core Developer
OSGrid Director
--0016e642d6d4d5f3570466a6ef33-- From cs@comlounge.net Fri Apr 3 08:15:34 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAF8A3A6A07 for ; Fri, 3 Apr 2009 08:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.374 X-Spam-Level: X-Spam-Status: No, score=-1.374 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599, J_CHICKENPOX_36=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 bON19J+3hY9R for ; Fri, 3 Apr 2009 08:15:33 -0700 (PDT) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 249ED3A6862 for ; Fri, 3 Apr 2009 08:15:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 5A5106F4011; Fri, 3 Apr 2009 17:16:34 +0200 (CEST) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zprumDO0Z2zL; Fri, 3 Apr 2009 17:16:32 +0200 (CEST) Received: from [192.168.178.34] (p5B395FAA.dip.t-dialin.net [91.57.95.170]) by post.comlounge.net (Postfix) with ESMTP id 166CF1CE0039; Fri, 3 Apr 2009 17:16:31 +0200 (CEST) Message-ID: <49D6284D.8050000@comlounge.net> Date: Fri, 03 Apr 2009 17:16:29 +0200 From: Christian Scholz User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Jon Watte References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <49D40A06.7030708@gmail.com> <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> <49D4295C.2020502@gmail.com> <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> <49D4E5AF.2030301@gmail.com> <49D51A7D.8000104@comlounge.net> <62BFE5680C037E4DA0B0A08946C0933D7B6934A3@rrsmsx506.amr.corp.intel.com> <49D52DCD.2000806@comlounge.net> <49D531DA.4080006@gmail.com> <49D533EA.4010301@comlounge.net> <49D54648.4020007@gmail.com> In-Reply-To: <49D54648.4020007@gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 15:15:34 -0000 Hi! Jon Watte wrote: > Christian Scholz wrote: >> The redirect setup is only one example of obtaining the OAuth token. >> You can do it whatever way you want to (the new version of the spec >> also makes that clearer as it starts with just the way you actually do >> authorized requests and only explains in the second part the redirect >> mechanism). >> > > When I register as a service provider for an OAuth service, I have to > register a callback URL. That seems pretty hard-coded into the actual > implementation to me. That service provider won't work with a service > that doesn't have a user-visible callbacl URL. > >> But if you look at e.g. iMovie and how it uploads movies to YouTube >> you have an example of how a desktop app can do it (although it's not >> using OAuth I think but probably Google AuthSub but it's basically the >> same). >> > > The problem is not the desktop app not being reachable; the problem is > the service requesting authentication not being reachable from the > authentication provider. So lets look at the spec as it is right now: http://tools.ietf.org/internet-drafts/draft-hammer-oauth-02.txt And maybe we should use the same terminology because I might simply be confused ;-) So we have: - a protected resource. This resides on a server and a client wants to access it on behalf of the server. Could e.g. be a photo - a client which wants to make an authenticated request to access the protected ressource. For instance it could be a desktop app as iMovie or it could be some server somewhere which wants to access e.g. this photo (or a simulator which wants to access avatar data) - a resource owner which is basically the user who owns that photo or avatar. (in the old spec there was a consumer which is now the client and a service provider which is now the server storing the protected resource). The main part of the new version of the specification is about how a client is supposed to do an authenticated request to obtain the protected resource. Basically it's using a token and client credentials to sign the request. The client credential identify the client and the token identify the resource owner (which need to have given consent to access it beforehand). If the signature is valid then access is granted. Section 4 of the specification defines how a token can be obtained by the client. But it also says that this is only one possible method. And this method actually involves the callback URI. If you now look in section 4.2 you see an OPTIONAL in the description of oauth_callback. It says: oauth_callback OPTIONAL. The client MAY specify an absolute URI for the server to redirect the resource owner back to the client when authorization has been obtained or denied. If no callback URI is defined (as it would be definitely true for desktop apps which can also act as a client) then the server simply informs the user that this step is finished and the next action needs to be taken in the client. Usually the user then switches back to the client desktop app or maybe web page and clicks "Continue". In an implementation with a web server as a client this might look like follows: 1. The client web server obtains a temporary token 2. The client web server opens a popup for the resource owner with the authorization URL of the server storing the protected resource 3. The resource owner (user) eventually logs into the server and gives consent for the client to access that data (in that popup) 4. The server then tells the resource owner to continue on the client and shows a "Close window" button. 5. The user clicks that and clicks "Continue" in the main web page of the client 6. The client then exchanges the temporary token with an access token behind the scenes. Here no callback URI is used but usability is maybe also a bit limited due to that. Now in the case of virtual worlds we probably have one more party: The VW client. So we have the following parties involved: - VW client: The desktop app for using the VW - VW server: The server the VW client connects to in the first place. It also acts as a client towards other servers hosting protected resources. - other servers: Those servers hosting e.g. the profile of a user or textures or 3D objects And here it becomes more complicated and there is maybe no solution yet to it. So this part might be what needs thinking in terms of: - How would authorization/authentication work at all in such a distributed environment? - How can this be implemented with e.g. OAuth (or other means)? I hope at least the first part of my reply answers your question regarding callback URIs. Of course another possibility would be to use a non-web based mechanism for the client to get hold of the access token. This might be defined in an OAuth Extension. -- Christian -- Christian Scholz Homepage: http://comlounge.net COM.lounge GmbH blog: http://mrtopf.de/blog Hanbrucher Str. 33 Skype: HerrTopf 52064 Aachen Video Blog: http://comlounge.tv Tel: +49 241 400 730 0 E-Mail cs@comlounge.net Fax: +49 241 979 00 850 IRC: MrTopf, Tao_T neuer Podcast: Der OpenWeb-Podcast (http://openweb-podcast.de) new podcast: Data Without Borders (http://datawithoutborders.net) From jwatte@gmail.com Fri Apr 3 10:23:52 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B843A28C2AA for ; Fri, 3 Apr 2009 10:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOqQ4u4CvsZA for ; Fri, 3 Apr 2009 10:23:51 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by core3.amsl.com (Postfix) with ESMTP id 77C9A3A68F6 for ; Fri, 3 Apr 2009 10:23:47 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so1085929rvb.49 for ; Fri, 03 Apr 2009 10:24:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=LVbpTWCk9HXP8opEV9JGt2WIYdL4/fwuU8Cxm+o5Wa8=; b=v7He5n7KcGf8+wPR1VmHeYzHwzSFdq9/Q6R+xyi5q2sZ+VJ8Bfa5eK/EoLgeia7wVC scvF+MReRzCiZ96U8wwTW5SocA+xPRseXpR/tRl62ID4Ckf1ZSBkJ5xNSJ0g3KGC455R CfMADcHrzkl3ox8chyCUfPRnSGFMKP5b2DcZ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=h8mI1VfAd2PAGdHWPRmV22ozKxCWvqRQrmKFBh9czFSIirG1PuCPjIMZyQ9iMz9sPM xnOUOulYQkT0dS29eC+MabUh+YSqa6/MPR0UoVl/oNq8seujyrKX43EC+8hZ7erXzM9a XYcXCYF0qb6rsJSm/gIbNAMBteLBRa+h88kVk= Received: by 10.141.193.9 with SMTP id v9mr649828rvp.120.1238779490054; Fri, 03 Apr 2009 10:24:50 -0700 (PDT) Received: from ?10.10.111.233? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id k41sm7620182rvb.36.2009.04.03.10.24.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 03 Apr 2009 10:24:49 -0700 (PDT) Message-ID: <49D64660.4060900@gmail.com> Date: Fri, 03 Apr 2009 10:24:48 -0700 From: Jon Watte User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Christian Scholz References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <49D40A06.7030708@gmail.com> <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> <49D4295C.2020502@gmail.com> <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> <49D4E5AF.2030301@gmail.com> <49D51A7D.8000104@comlounge.net> <62BFE5680C037E4DA0B0A08946C0933D7B6934A3@rrsmsx506.amr.corp.intel.com> <49D52DCD.2000806@comlounge.net> <49D531DA.4080006@gmail.com> <49D533EA.4010301@comlounge.net> <49D54648.4020007@gmail.com> <49D6284D.8050000@comlounge.net> In-Reply-To: <49D6284D.8050000@comlounge.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 17:23:52 -0000 Christian Scholz wrote: > So lets look at the spec as it is right now: > http://tools.ietf.org/internet-drafts/draft-hammer-oauth-02.txt > > And maybe we should use the same terminology because I might simply be > confused ;-) > That is a re-wording and clarification of the version I had previously read. I guess the question then is whether service provider implementations require the callback URL in their implementation, or whether they'll be OK with a NULL callback URL. I know of at least one service provider that has a form submission to obtain an application key where the callback URL cannot be left empty, but maybe it can be redirected to some URI that does nothing. Regarding service discovery: Does anyone want to start talking about XRDS? http://xrds-simple.net/core/1.0/ Sincerely, jw From john.hurliman@intel.com Fri Apr 3 11:03:27 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 382B128C1FC for ; Fri, 3 Apr 2009 11:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.414 X-Spam-Level: X-Spam-Status: No, score=-6.414 tagged_above=-999 required=5 tests=[AWL=0.185, 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 kiEZylQxPDzF for ; Fri, 3 Apr 2009 11:03:26 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by core3.amsl.com (Postfix) with ESMTP id 51F5C28C187 for ; Fri, 3 Apr 2009 11:03:26 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 03 Apr 2009 10:55:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.39,320,1235980800"; d="scan'208";a="503400682" Received: from rrsmsx604.amr.corp.intel.com ([10.31.0.170]) by orsmga001.jf.intel.com with ESMTP; 03 Apr 2009 11:03:58 -0700 Received: from rrsmsx601.amr.corp.intel.com (10.31.0.151) by rrsmsx604.amr.corp.intel.com (10.31.0.170) with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 3 Apr 2009 12:04:28 -0600 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Fri, 3 Apr 2009 12:04:27 -0600 From: "Hurliman, John" To: Jon Watte , Christian Scholz Date: Fri, 3 Apr 2009 12:04:23 -0600 Thread-Topic: [mmox] OGP scalability concerns Thread-Index: Acm0gRjyFQ8+Hh68R9WKARy9QBctbQABXjug Message-ID: <62BFE5680C037E4DA0B0A08946C0933D7B94D218@rrsmsx506.amr.corp.intel.com> References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <49D40A06.7030708@gmail.com> <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> <49D4295C.2020502@gmail.com> <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> <49D4E5AF.2030301@gmail.com> <49D51A7D.8000104@comlounge.net> <62BFE5680C037E4DA0B0A08946C0933D7B6934A3@rrsmsx506.amr.corp.intel.com> <49D52DCD.2000806@comlounge.net> <49D531DA.4080006@gmail.com> <49D533EA.4010301@comlounge.net> <49D54648.4020007@gmail.com> <49D6284D.8050000@comlounge.net> <49D64660.4060900@gmail.com> In-Reply-To: <49D64660.4060900@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 18:03:27 -0000 >-----Original Message----- >From: Jon Watte [mailto:jwatte@gmail.com] >Sent: Friday, April 03, 2009 10:25 AM >To: Christian Scholz >Cc: Hurliman, John; mmox@ietf.org >Subject: Re: [mmox] OGP scalability concerns > >Christian Scholz wrote: >> So lets look at the spec as it is right now: >> http://tools.ietf.org/internet-drafts/draft-hammer-oauth-02.txt >> >> And maybe we should use the same terminology because I might simply be >> confused ;-) >> > >That is a re-wording and clarification of the version I had previously >read. > >I guess the question then is whether service provider implementations >require the callback URL in their implementation, or whether they'll be >OK with a NULL callback URL. I know of at least one service provider >that has a form submission to obtain an application key where the >callback URL cannot be left empty, but maybe it can be redirected to >some URI that does nothing. > >Regarding service discovery: Does anyone want to start talking about >XRDS? >http://xrds-simple.net/core/1.0/ > >Sincerely, > >jw Yes From markl@lindenlab.com Fri Apr 3 11:23:14 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFB503A6358 for ; Fri, 3 Apr 2009 11:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.55 X-Spam-Level: X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 TuphAkEFICdM for ; Fri, 3 Apr 2009 11:23:14 -0700 (PDT) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 15E553A6D61 for ; Fri, 3 Apr 2009 11:23:09 -0700 (PDT) Received: from nil.lindenlab.com (nil.lindenlab.com [10.1.16.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 187393DBC48A; Fri, 3 Apr 2009 11:24:12 -0700 (PDT) Message-Id: <14FA8471-0BA2-42C8-8A09-3BEA6AA50E69@lindenlab.com> From: Mark Lentczner To: Second Life Developer Mailing List , MMOX-IETF Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 3 Apr 2009 11:24:11 -0700 X-Mailer: Apple Mail (2.930.3) Subject: [mmox] Zero's Office Hours, April 7th X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 18:23:14 -0000 My in-world (Second Life) office hours will be held next Tuesday, April 7th, from 1pm to 3pm. Please place agenda items for consideration on my wiki page: https://wiki.secondlife.com/wiki/User:Zero_Linden Preference will be given to agenda items with concrete technical discussion, especially those with written documentation available prior to the meeting. Please link documentation from the wiki page. For those that haven't attended before, my office hours are held once a month to discuss the development of the OGP protocol, and other technical issues about the architecture of systems that can/could support OGP. The discussion is held in Second Life, using text chat, and transcripts are published publicly (see the wiki page.) - Mark / Zero Mark Lentczner Sr. Systems Architect Technology Integration Linden Lab markl@lindenlab.com Zero Linden zero.linden@secondlife.com From dwl@us.ibm.com Fri Apr 3 12:57:20 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B94B23A67D1; Fri, 3 Apr 2009 12:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.885 X-Spam-Level: X-Spam-Status: No, score=-5.885 tagged_above=-999 required=5 tests=[AWL=0.713, 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 7jyxLc6NZAbp; Fri, 3 Apr 2009 12:57:19 -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 0A9643A682E; Fri, 3 Apr 2009 12:57:18 -0700 (PDT) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e3.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n33Jt2g4027992; Fri, 3 Apr 2009 15:55:02 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n33JwLJh192978; Fri, 3 Apr 2009 15:58:21 -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 n33JwLIX029559; Fri, 3 Apr 2009 15:58:21 -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 n33JwKLu029556; Fri, 3 Apr 2009 15:58:20 -0400 In-Reply-To: <14FA8471-0BA2-42C8-8A09-3BEA6AA50E69@lindenlab.com> References: <14FA8471-0BA2-42C8-8A09-3BEA6AA50E69@lindenlab.com> To: MMOX-IETF , mmox-bounces@ietf.org MIME-Version: 1.0 X-KeepSent: FD8E28E4:B984AE3B-8525758D:006D4CB9; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 Message-ID: From: David W Levine Date: Fri, 3 Apr 2009 15:58:20 -0400 X-MIMETrack: Serialize by Router on D01ML605/01/M/IBM(Release 8.5|December 05, 2008) at 04/03/2009 15:58:20, Serialize complete at 04/03/2009 15:58:20 Content-Type: multipart/alternative; boundary="=_alternative 006DB5D28525758D_=" Subject: [mmox] Layering and separation of concerns... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 19:57:20 -0000 This is a multipart message in MIME format. --=_alternative 006DB5D28525758D_= Content-Type: text/plain; charset="US-ASCII" Between a bunch of the discussion here, and some of the discussion last week at the IETF BOF, I've noticed a fair bit of what I'd describe as getting lost in the layering. A lot of this seems to happen because the Linden Lab grid is the main way people think about the problem space. The OGP drafts are pretty deeply steeped in Linden's terminology, and deployment model. OpenSim, tho different in some ways, is also a very specific bundling of function, and one who's shape is pretty strongly influenced by the shared Second Life viewer. I'd like to try and push fairly hard, to pull apart some important things, which *should* be thought of as totally separate. MMOX and OGP are attempts to describe a set of services, protocols, and serializations which will enhance interoperability in the Virtual Worlds/Immersive experience technology space. Starting most abstractly, OGP, and MMOX, describe an approach to solving the overall problem of creating and sharing the presentation of virtual spaces across many potential participants. We can then think of that approach as being broken up into a set of abstract building blocks, which are roughly speaking sets of named web resources, and services/protocols to map those building blocks onto internet deliverable chunks of function. Those chunks of functions get defined in detail (mostly as REST resources and protocols managed by the services, and in some low level mapping of concrete data structures onto web appropriate (read, XMLish or other structured format) representations. For added fun, we try, very hard to separate mechanism from policy, so that, we can speak of the set of REST resources which deliver a service in the model, and the set of policies which may control the use of that service. Finally, we have to separate in our heads, implementations and deployments of these services from their specifications. This frankly, along with the separation of mechanism from policy seems to be where we tend to get in trouble. Again, I think this to a very real extent stems from thinking very concretely about the current Linden Lab's SecondLife deployment, and from a set of documents which is very closely coupled to that deployment model. Exactly how people cluster services, should be, to a *very* large extent, separate from any specifications we create as part of the IETF/MMOX process. How they deploy services, the policies they apply to their deployments and the details of their implementations are totally outside of out interest, except when they impose constraints or requirements which affect interoperability. So, should a major set of deployers find a function missing, or impossible to separate from another function, that would be cogent input, and presumably shape future versions of the specifications. Any single implementer and deployer's choices of *how* to run their services, should be largely irrelevant. If you are still paying attention. 1) I don't believe *anything* in the way OGP gets defined as a set of services will dictate whitelists, blacklists, or similar common approaches to managing access. I firmly believe that we will put the right things into the protocol to permit people to build and deploy MMOX software which can use such techniques. I also, once again, observe that a core notion I have been advocating for a very long time, is to include the protocol elements permitting policy choices to be made, and then, permit people to not provide things such as authentication tokens, with the understanding that they may receive traditional web style 401 errors, if they don't provide those tokens to services which expect them. 2) There are a number of very different deployer models represented on the mailing list. Some, such as Linden Lab, and some large enterprise users, may have strong desires to bundle set of services to meet their needs. Others, may wish to unbundle some of the services, and deploy them independently. The only impact this ought to have on the actual services, is to levy a requirement that services not be overly coupled. Said requirement is inherent in good architecture, and should not be terribly controversial. At the same time, any single deployer, or contributor to this process, should be respectful of the full range of requirements we are trying to address. Dismissing someone else's use case as "not valid" is generally counterproductive. Understanding the use cases, and the desires which motivate them, and then working together to understand how we can support as broad a range of use cases as possible, is, in some very real sense the heart of the process. There are some nasty, hungry dragons in the "decompose the set of services very broadly" approach. It is possible to go from too tightly a coupled solution, where interop is obvious and inherent to too loosely a coupled solution where it is possible for two implementations to be fully conformant, and totally non interoperable. Classically such problems are addressed with "profiles" with decidedly mixed results. That said, I urge people to think very hard, as to at what level of layering something they find objectionable occurs. Look at whether we are conflating deployment and implementation choices as with design choices at the architecture and framework level - Catching up, very slowly, on MMOX mail, after 4 days off chasing dead hard drives and stuff stack up in the office, - David W. Levine ~ Zha Ewry (ISL) . --=_alternative 006DB5D28525758D_= Content-Type: text/html; charset="US-ASCII"
Between a bunch of the discussion here, and some of the discussion
last week at the IETF BOF, I've noticed a fair bit of what I'd
describe as getting lost in the layering. A lot of this seems to
happen because the Linden Lab grid is the main way people think about
the problem space. The OGP drafts are pretty deeply steeped in
Linden's terminology, and deployment model. OpenSim, tho different in
some ways, is also a very specific bundling of function, and one who's
shape is pretty strongly influenced by the shared Second Life viewer.

I'd like to try and push fairly hard, to pull apart some important
things, which *should* be thought of as totally separate.

MMOX and OGP are attempts to describe a set of services, protocols,
and serializations which will enhance interoperability in the Virtual
Worlds/Immersive experience technology space.

Starting most abstractly, OGP, and MMOX, describe an approach to
solving the overall problem of creating and sharing the presentation
of virtual spaces across many potential participants. We can then
think of that approach as being broken up into a set of abstract
building blocks, which are roughly speaking sets of named web
resources, and services/protocols to map those building blocks onto
internet deliverable chunks of function. Those chunks of functions get
defined in detail (mostly as REST resources and protocols managed by
the services, and in some low level mapping of concrete data
structures onto web appropriate (read, XMLish or other structured
format) representations.

For added fun, we try, very hard to separate mechanism from policy, so
that, we can speak of the set of REST resources which deliver a
service in the model, and the set of policies which may control the
use of that service.

Finally, we have to separate in our heads, implementations and
deployments of these services from their specifications. This frankly,
along with the separation of mechanism from policy seems to be where we
tend to get in trouble. Again, I think this to a very real extent
stems from thinking very concretely about the current Linden Lab's
SecondLife deployment, and from a set of documents which is very
closely coupled to that deployment model.

Exactly how people cluster services, should be, to a *very* large
extent, separate from any specifications we create as part of the
IETF/MMOX process. How they deploy services, the policies they apply
to their deployments and the details of their implementations are
totally outside of out interest, except when they impose constraints
or requirements which affect interoperability. So, should a major set
of deployers find a function missing, or impossible to separate from
another function, that would be cogent input, and presumably shape
future versions of the specifications. Any single implementer and
deployer's choices of *how* to run their services, should be largely
irrelevant.

If you are still paying attention.

1) I don't believe *anything* in the way OGP gets defined as a set of
services will dictate whitelists, blacklists, or similar common
approaches to managing access. I firmly believe that we will put the
right things into the protocol to permit people to build and deploy
MMOX software which can use such techniques. I also, once again,
observe that a core notion I have been advocating for a very long
time, is to include the protocol elements permitting policy choices to
be made, and then, permit people to not provide things such as
authentication tokens, with the understanding that they may receive
traditional web style 401 errors, if they don't provide those tokens to
services which expect them.

2) There are a number of very different deployer models represented on
the mailing list. Some, such as Linden Lab, and some large enterprise
users, may have strong desires to bundle set of services to meet their
needs. Others, may wish to unbundle some of the services, and deploy
them independently. The only impact this ought to have on the actual
services, is to levy a requirement that services not be overly
coupled. Said requirement is inherent in good architecture, and should
not be terribly controversial.

At the same time, any single deployer, or contributor to this process,
should be respectful of the full range of requirements we are trying
to address. Dismissing someone else's use case as "not valid" is
generally counterproductive. Understanding the use cases, and the
desires which motivate them, and then working together to understand how
we can support as broad a range of use cases as possible, is, in some
very real sense the heart of the process.

There are some nasty, hungry dragons in the "decompose the set of
services very broadly" approach. It is possible to go from too tightly
a coupled solution, where interop is obvious and inherent to too
loosely a coupled solution where it is possible for two implementations
to be fully conformant, and totally non interoperable. Classically
such problems are addressed with "profiles" with decidedly mixed
results.

That said, I urge people to think very hard, as to at what level of
layering  something they find objectionable occurs. Look at whether we are
conflating deployment and implementation choices as with design choices at the
architecture and framework level

- Catching up, very slowly, on MMOX mail, after 4 days off chasing dead hard drives
and stuff stack up in the office,

- David W. Levine
~ Zha Ewry (ISL)
.

--=_alternative 006DB5D28525758D_=-- From dhc2@dcrocker.net Fri Apr 3 13:21:10 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BD233A69F1 for ; Fri, 3 Apr 2009 13:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 txYXJNbEMRag for ; Fri, 3 Apr 2009 13:21:09 -0700 (PDT) Received: from sbh17.songbird.com (mail.mipassoc.org [IPv6:2001:470:1:76:0:ffff:4834:7146]) by core3.amsl.com (Postfix) with ESMTP id 791063A69AB for ; Fri, 3 Apr 2009 13:21:09 -0700 (PDT) Received: from [127.0.0.1] (adsl-67-127-191-236.dsl.pltn13.pacbell.net [67.127.191.236]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n33KM5MD026825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Apr 2009 13:22:10 -0700 Message-ID: <49D66FED.2090509@dcrocker.net> Date: Fri, 03 Apr 2009 13:22:05 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Mark Lentczner References: <14FA8471-0BA2-42C8-8A09-3BEA6AA50E69@lindenlab.com> In-Reply-To: <14FA8471-0BA2-42C8-8A09-3BEA6AA50E69@lindenlab.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, 03 Apr 2009 13:22:10 -0700 (PDT) Cc: Second Life Developer Mailing List , MMOX-IETF Subject: Re: [mmox] Zero's Office Hours, April 7th X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 20:21:10 -0000 Mark Lentczner wrote: > My in-world (Second Life) office hours will be held next Tuesday, April > 7th, from 1pm to 3pm. what timezone? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From markl@lindenlab.com Fri Apr 3 17:11:59 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA4653A6883 for ; Fri, 3 Apr 2009 17:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.555 X-Spam-Level: X-Spam-Status: No, score=-3.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 U2pxpsvcVcXd for ; Fri, 3 Apr 2009 17:11:59 -0700 (PDT) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 4E4053A687E for ; Fri, 3 Apr 2009 17:11:59 -0700 (PDT) Received: from nil.lindenlab.com (nil.lindenlab.com [10.1.16.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 3BCCC1414003; Fri, 3 Apr 2009 17:13:02 -0700 (PDT) Message-Id: From: Mark Lentczner To: Second Life Developer Mailing List , MMOX-IETF Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 3 Apr 2009 17:13:02 -0700 X-Mailer: Apple Mail (2.930.3) Subject: [mmox] Zero's Office Hours, April 7th -- now with timezone info! X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 00:12:00 -0000 D'oh, forgot the timezone info: My in-world (Second Life) office hours will be held next Tuesday, April 7th, from 1pm to 3pm ** PDT or UTC-0700 ** - Mark / Zero Mark Lentczner Sr. Systems Architect Technology Integration Linden Lab markl@lindenlab.com Zero Linden zero.linden@secondlife.com From cs@comlounge.net Sat Apr 4 05:41:41 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7E9A3A68EF for ; Sat, 4 Apr 2009 05:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, J_CHICKENPOX_36=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 NxNS83zSEuMn for ; Sat, 4 Apr 2009 05:41:40 -0700 (PDT) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 7B34A3A6843 for ; Sat, 4 Apr 2009 05:41:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 797696F401D; Sat, 4 Apr 2009 14:42:42 +0200 (CEST) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Cpn5IQ1uwrJ; Sat, 4 Apr 2009 14:42:41 +0200 (CEST) Received: from [192.168.2.101] (pC19EAF64.dip.t-dialin.net [193.158.175.100]) by post.comlounge.net (Postfix) with ESMTP id E4FF76F401B; Sat, 4 Apr 2009 14:42:40 +0200 (CEST) Message-ID: <49D755C1.7050902@comlounge.net> Date: Sat, 04 Apr 2009 14:42:41 +0200 From: Christian Scholz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Mark Lentczner References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Second Life Developer Mailing List , MMOX-IETF Subject: Re: [mmox] Zero's Office Hours, April 7th -- now with timezone info! X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 12:41:42 -0000 Mark Lentczner schrieb: > D'oh, forgot the timezone info: > > My in-world (Second Life) office hours will be held next Tuesday, April > 7th, from 1pm to 3pm ** PDT or UTC-0700 ** So that's 2000 UTC and here is a handy chart: http://timeanddate.com/worldclock/fixedtime.html?day=7&month=4&year=2009&hour=13&min=0&sec=0&p1=247 -- Christian -- COM.lounge GmbH http://comlounge.net Hanbrucher Strasse 33, 52064 Aachen Amtsgericht Aachen HRB 15170 Geschäftsführer: Dr. Ben Scheffler, Christian Scholz email: info@comlounge.net fon: +49-241-4007300 fax: +49-241-97900850 personal email: cs@comlounge.net personal blog: http://mrtopf.de/blog personal podcasts: http://openweb-podcast.de, http://datawithoutborders.net From cs@comlounge.net Mon Apr 6 14:55:47 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B8563A6866 for ; Mon, 6 Apr 2009 14:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.114 X-Spam-Level: X-Spam-Status: No, score=-2.114 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, J_CHICKENPOX_36=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 6vPt-xPFOm2e for ; Mon, 6 Apr 2009 14:55:39 -0700 (PDT) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 8E2643A6885 for ; Mon, 6 Apr 2009 14:55:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id EBBBE1CE016F; Mon, 6 Apr 2009 23:56:41 +0200 (CEST) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oq9CsbNi6MaD; Mon, 6 Apr 2009 23:56:40 +0200 (CEST) Received: from [192.168.2.101] (pC19EAFC7.dip.t-dialin.net [193.158.175.199]) by post.comlounge.net (Postfix) with ESMTP id EB5D21CE00EA; Mon, 6 Apr 2009 23:56:39 +0200 (CEST) Message-ID: <49DA7A95.4010303@comlounge.net> Date: Mon, 06 Apr 2009 23:56:37 +0200 From: Christian Scholz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Jon Watte References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <49D40A06.7030708@gmail.com> <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> <49D4295C.2020502@gmail.com> <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> <49D4E5AF.2030301@gmail.com> <49D51A7D.8000104@comlounge.net> <62BFE5680C037E4DA0B0A08946C0933D7B6934A3@rrsmsx506.amr.corp.intel.com> <49D52DCD.2000806@comlounge.net> <49D531DA.4080006@gmail.com> <49D533EA.4010301@comlounge.net> <49D54648.4020007@gmail.com> <49D6284D.8050000@comlounge.net> <49D64660.4060900@gmail.com> In-Reply-To: <49D64660.4060900@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "mmox@ietf.org" Subject: Re: [mmox] OGP scalability concerns X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 21:55:47 -0000 Jon Watte schrieb: > Christian Scholz wrote: >> So lets look at the spec as it is right now: >> http://tools.ietf.org/internet-drafts/draft-hammer-oauth-02.txt >> >> And maybe we should use the same terminology because I might simply be >> confused ;-) >> > > That is a re-wording and clarification of the version I had previously > read. Right. > I guess the question then is whether service provider implementations > require the callback URL in their implementation, or whether they'll be > OK with a NULL callback URL. I know of at least one service provider > that has a form submission to obtain an application key where the > callback URL cannot be left empty, but maybe it can be redirected to > some URI that does nothing. Remember that OAuth is still fairly new and not all use cases or best practices have been researched fully yet. But now with Twitter also moving towards OAuth more people discover some potential problems such as that callback URL, e.g. iPhone applications. There is some workaround though which was discussed regarding those apps which is using a protocol handler, e.g. secondlife:oauth_success which could then be catched by that respective application in case of desktop or iPhone apps. You can of course also simply redirect to a dummy URI which simply instructs the user to click "Continue" on the original web page. > Regarding service discovery: Does anyone want to start talking about XRDS? > http://xrds-simple.net/core/1.0/ Of course, although it's probably replaced soon by the XRD spec (sneak peak and examples here: http://www.hueniverse.com/hueniverse/2009/03/xrd-weekly-recap.html So I guess we should name our little project simply "Service Discovery" and we need to find out what we actually want to do. The XRD spec for describing resources and the LRRD spec for discovering where to find the XRD document are already being written so our task might be to check if and how they are applicable to our problem space. So we might need some use cases and requirements and the output might eventually be some description of how to apply the XRD suite to our problem. I personally would be very much interested in what bigger parts a virtual world might actually consist of. Right now I guess it's a client and a server (or a cluster) in most cases, except Croquet which is only clients (is that right?). Now if we decompose things the question is how the actual workflow from starting the client to appearing in some simulator for other users might look like. And how moving from one simulator to another (usually called teleport, technically a login or handshake) might look like. -- Christian -- COM.lounge GmbH http://comlounge.net Hanbrucher Strasse 33, 52064 Aachen Amtsgericht Aachen HRB 15170 Geschäftsführer: Dr. Ben Scheffler, Christian Scholz email: info@comlounge.net fon: +49-241-4007300 fax: +49-241-97900850 personal email: cs@comlounge.net personal blog: http://mrtopf.de/blog personal podcasts: http://openweb-podcast.de, http://datawithoutborders.net From cs@comlounge.net Mon Apr 6 15:04:31 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A18AB3A6940; Mon, 6 Apr 2009 15:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=-1.316, BAYES_40=-0.185, J_CHICKENPOX_36=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 jlOiAwyUsJES; Mon, 6 Apr 2009 15:04:30 -0700 (PDT) Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id C055E3A676A; Mon, 6 Apr 2009 15:04:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 84E341CE016F; Tue, 7 Apr 2009 00:05:33 +0200 (CEST) Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BinYH-4WtqwO; Tue, 7 Apr 2009 00:05:30 +0200 (CEST) Received: from [192.168.2.101] (pC19EAFC7.dip.t-dialin.net [193.158.175.199]) by post.comlounge.net (Postfix) with ESMTP id 0201A1CE00EA; Tue, 7 Apr 2009 00:05:29 +0200 (CEST) Message-ID: <49DA7CA7.8000408@comlounge.net> Date: Tue, 07 Apr 2009 00:05:27 +0200 From: Christian Scholz User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: David W Levine References: <14FA8471-0BA2-42C8-8A09-3BEA6AA50E69@lindenlab.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: mmox-bounces@ietf.org, MMOX-IETF Subject: Re: [mmox] Layering and separation of concerns... X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 22:04:31 -0000 David W Levine schrieb: > > Between a bunch of the discussion here, and some of the discussion > last week at the IETF BOF, I've noticed a fair bit of what I'd > describe as getting lost in the layering. A lot of this seems to > happen because the Linden Lab grid is the main way people think about > the problem space. The OGP drafts are pretty deeply steeped in > Linden's terminology, and deployment model. OpenSim, tho different in > some ways, is also a very specific bundling of function, and one who's > shape is pretty strongly influenced by the shared Second Life viewer. > > I'd like to try and push fairly hard, to pull apart some important > things, which *should* be thought of as totally separate. [...] > Exactly how people cluster services, should be, to a *very* large > extent, separate from any specifications we create as part of the > IETF/MMOX process. How they deploy services, the policies they apply > to their deployments and the details of their implementations are > totally outside of out interest, except when they impose constraints > or requirements which affect interoperability. So, should a major set > of deployers find a function missing, or impossible to separate from > another function, that would be cogent input, and presumably shape > future versions of the specifications. Any single implementer and > deployer's choices of *how* to run their services, should be largely > irrelevant. +1 > If you are still paying attention. > > 1) I don't believe *anything* in the way OGP gets defined as a set of > services will dictate whitelists, blacklists, or similar common > approaches to managing access. I firmly believe that we will put the > right things into the protocol to permit people to build and deploy > MMOX software which can use such techniques. I also, once again, > observe that a core notion I have been advocating for a very long > time, is to include the protocol elements permitting policy choices to > be made, and then, permit people to not provide things such as > authentication tokens, with the understanding that they may receive > traditional web style 401 errors, if they don't provide those tokens to > services which expect them. I am not sure I get this sentence ;-) So are you saying that if a user does not provide some means of authentication to a service he has to expect a 401 response? Seems logical (and how it's described in the OAuth spec IIRC plus during some AWG meeting). > 2) There are a number of very different deployer models represented on > the mailing list. Some, such as Linden Lab, and some large enterprise > users, may have strong desires to bundle set of services to meet their > needs. Others, may wish to unbundle some of the services, and deploy > them independently. The only impact this ought to have on the actual > services, is to levy a requirement that services not be overly > coupled. Said requirement is inherent in good architecture, and should > not be terribly controversial. Right. Also many API specs do exist already at least for the 2D space which could be used if they fulfill all requirements we have (but I don't expect them to be too different from e.g. social networks in these cases). > At the same time, any single deployer, or contributor to this process, > should be respectful of the full range of requirements we are trying > to address. Dismissing someone else's use case as "not valid" is > generally counterproductive. Understanding the use cases, and the > desires which motivate them, and then working together to understand how > we can support as broad a range of use cases as possible, is, in some > very real sense the heart of the process. +1 > There are some nasty, hungry dragons in the "decompose the set of > services very broadly" approach. It is possible to go from too tightly > a coupled solution, where interop is obvious and inherent to too > loosely a coupled solution where it is possible for two implementations > to be fully conformant, and totally non interoperable. Classically > such problems are addressed with "profiles" with decidedly mixed > results. Again in the 2D space there is some precedence in things like OpenSocial and the like. Using such formats would also give us the possibilty to hook up with existing social networks more easily. In the 3D space things might be more complicated maybe simply because there is not so much work being done yet in specifying interoperable formats and protocols. > That said, I urge people to think very hard, as to at what level of > layering something they find objectionable occurs. Look at whether we are > conflating deployment and implementation choices as with design choices > at the > architecture and framework level > > - Catching up, very slowly, on MMOX mail, after 4 days off chasing dead > hard drives > and stuff stack up in the office, I hope your hard drives are living again :-) -- Christian -- COM.lounge GmbH http://comlounge.net Hanbrucher Strasse 33, 52064 Aachen Amtsgericht Aachen HRB 15170 Geschäftsführer: Dr. Ben Scheffler, Christian Scholz email: info@comlounge.net fon: +49-241-4007300 fax: +49-241-97900850 personal email: cs@comlounge.net personal blog: http://mrtopf.de/blog personal podcasts: http://openweb-podcast.de, http://datawithoutborders.net From stevey@amsl.com Fri Apr 10 14:23:50 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 737143A6B6F for ; Fri, 10 Apr 2009 14:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.106 X-Spam-Level: ** X-Spam-Status: No, score=2.106 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] 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 Ri01PrLgRYs0 for ; Fri, 10 Apr 2009 14:23:49 -0700 (PDT) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1890:1112:1::14]) by core3.amsl.com (Postfix) with ESMTP id DB1073A68AE for ; Fri, 10 Apr 2009 14:23:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by core2.amsl.com (Postfix) with ESMTP id 11E7E24070 for ; Fri, 10 Apr 2009 14:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([64.170.98.20]) by localhost (core2.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgjzBLZqEl37 for ; Fri, 10 Apr 2009 14:25:07 -0700 (PDT) Received: from steveyPC (adsl-69-236-186-209.dsl.pltn13.pacbell.net [69.236.186.209]) by core2.amsl.com (Postfix) with ESMTP id DBCE223FBF for ; Fri, 10 Apr 2009 14:25:06 -0700 (PDT) From: "Steve Young" To: Date: Fri, 10 Apr 2009 14:24:42 -0700 Message-ID: <000301c9ba22$c358a230$4a09e690$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C9B9E8.16F9CA30" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acm6IsModa3pMsWQR2mWFv8sbkwCVw== Content-Language: en-us X-Mailman-Approved-At: Fri, 10 Apr 2009 14:24:21 -0700 Subject: [mmox] Test - please ignore X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 21:23:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0004_01C9B9E8.16F9CA30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Test message to trace any issues with mmox mailing list and archiving. Steve AMS ------=_NextPart_000_0004_01C9B9E8.16F9CA30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Test message to trace any issues with mmox mailing list = and archiving.

 

Steve

AMS

 

------=_NextPart_000_0004_01C9B9E8.16F9CA30-- From infinity@lindenlab.com Fri Apr 10 14:43:54 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 965C53A6A88 for ; Fri, 10 Apr 2009 14:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.404 X-Spam-Level: X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=-1.024, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, TVD_SPACE_RATIO=2.219] 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 PVRHlmfgQPGp for ; Fri, 10 Apr 2009 14:43:54 -0700 (PDT) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 267023A69F1 for ; Fri, 10 Apr 2009 14:43:54 -0700 (PDT) Received: from openvpn-client-A-158.lindenlab.com (openvpn-client-A-158.lindenlab.com [10.8.0.158]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 613223DBC44A for ; Fri, 10 Apr 2009 14:45:03 -0700 (PDT) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: mmox@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 10 Apr 2009 14:45:02 -0700 X-Mailer: Apple Mail (2.930.3) Subject: [mmox] testing again... testing... testing X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2009 21:43:54 -0000 From wjgeorge@dceo.rutgers.edu Mon Apr 13 06:53:07 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3147F3A689C for ; Mon, 13 Apr 2009 06:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.397 X-Spam-Level: X-Spam-Status: No, score=-0.397 tagged_above=-999 required=5 tests=[AWL=-1.021, BAYES_50=0.001, 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 5DMgxnZ6BlYJ for ; Mon, 13 Apr 2009 06:53:05 -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 3EDEF3A68EF for ; Mon, 13 Apr 2009 06:53:04 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d11so1872393and.4 for ; Mon, 13 Apr 2009 06:54:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.251.14 with SMTP id y14mr7663775anh.40.1239630855070; Mon, 13 Apr 2009 06:54:15 -0700 (PDT) Date: Mon, 13 Apr 2009 09:54:15 -0400 Message-ID: <27a487810904130654n3d8e69abye1c6c98c18a147a9@mail.gmail.com> From: William George To: mmox@ietf.org Content-Type: multipart/alternative; boundary=00163691fefcc4e8b80467700c65 Subject: [mmox] Cryengine 2 screenshots from Extropia X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 13:53:07 -0000 --00163691fefcc4e8b80467700c65 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Shows what a more advanced environment engine can provide. Anyone seen any from Blue Mars? http://planetcalypso.com/news/pages/2009/04/09/7346/index.xml --00163691fefcc4e8b80467700c65 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Shows what a more advanced environment engine can provide. Anyone seen any from Blue Mars?

http://planetcalypso.com/news/pages/2009/04/09/7346/index.xml


--00163691fefcc4e8b80467700c65-- From dcolivares@gmail.com Mon Apr 13 07:20:21 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38CA63A6DE0 for ; Mon, 13 Apr 2009 07:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 Kwb+Zn2D72vq for ; Mon, 13 Apr 2009 07:20:20 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by core3.amsl.com (Postfix) with ESMTP id E19153A6DAD for ; Mon, 13 Apr 2009 07:20:17 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so1736071rvb.49 for ; Mon, 13 Apr 2009 07:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LayluJfl+WSs1ep/TPknkrLXpTrU/LfsIrzpZgfS7l0=; b=aRafQU02jqFbAF7OXGzSbL+N1fzcBsgxgjWC4+pWkvgD1eUYwXy3g5oQLKPyKJuki0 g8l/+cs2w0axe9ee8OEa0pDo16wM5xMeWYeTcGemKH3ztk1Wgh2iezyfaOmelhnh/8Fo JoF2AvuXgeYJzNPwfUv5ePVnfGvEpMuXyHnVY= 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=FILVM8z6pAR/h3HrenhfIGbFWOqwK7xxH80StxTOqdluddDssGmYV40ZwvK87GF7pg xxfrcjyzpub/HVyfBvRT5yEjdazAw92RSMXwaW0m3FXUX3xWYY91/B9uby45vJ76tfBO 1PxWspDvzTW23dW3mVTV7YMt0vlVN50yTBqp8= MIME-Version: 1.0 Received: by 10.140.140.3 with SMTP id n3mr2778613rvd.111.1239632488766; Mon, 13 Apr 2009 07:21:28 -0700 (PDT) In-Reply-To: <27a487810904130654n3d8e69abye1c6c98c18a147a9@mail.gmail.com> References: <27a487810904130654n3d8e69abye1c6c98c18a147a9@mail.gmail.com> Date: Mon, 13 Apr 2009 10:21:28 -0400 Message-ID: From: Dan Olivares To: William George Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Cryengine 2 screenshots from Extropia X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 14:20:21 -0000 More advanced then what? What are you comparing it to? Best Regards Dan On Mon, Apr 13, 2009 at 9:54 AM, William George wrote: > Shows what a more advanced environment engine can provide. Anyone seen any > from Blue Mars? > > http://planetcalypso.com/news/pages/2009/04/09/7346/index.xml > > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > > From infinity@lindenlab.com Mon Apr 13 10:17:44 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B03FA3A6D8E for ; Mon, 13 Apr 2009 10:17:44 -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=[BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 dSKApVC2rdIm for ; Mon, 13 Apr 2009 10:17:43 -0700 (PDT) Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 287A23A6818 for ; Mon, 13 Apr 2009 10:17:43 -0700 (PDT) Received: from [192.168.2.3] (adsl-75-30-244-57.dsl.pltn13.sbcglobal.net [75.30.244.57]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id B12193DBC06C; Mon, 13 Apr 2009 10:18:53 -0700 (PDT) Message-Id: From: "Meadhbh Hamrick (Infinity)" To: William George In-Reply-To: <27a487810904130654n3d8e69abye1c6c98c18a147a9@mail.gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-1--657072438 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 13 Apr 2009 10:18:52 -0700 References: <27a487810904130654n3d8e69abye1c6c98c18a147a9@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: mmox@ietf.org Subject: Re: [mmox] Cryengine 2 screenshots from Extropia X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 17:17:44 -0000 --Apple-Mail-1--657072438 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit oooh.. john bates is gonna hate me for saying this... but... fwiw... i think we're all (all of us who make virtual worlds) in an era where photorealistic rendering is more or less cheap and readily assessable. the thing i noticed when following john in world was that virtually _all_ the plants looked identical. we sometimes get the same effect in second life when you build an area with a limited number of "stock" shapes / textures. in SL, there's a tradeoff between texture load time and visual diversity. on one hand you could have every virtual object have it's own shape / prim, and every prim have it's own texture. this would enhance visual diversity. but it would probably be dog slow to load and who knows... you might even make low- end systems with not quite enough texture memory barf. on the other, you could have a set of stock shapes / texture and reuse them. this would load quicker, but it would be a challenge to make it visually appealing. i don't know that it would be impossible, only that it would be difficult. and... different people have a different idea for what "visually appealing" means to them. so... i finally saw a blue mars demo at GDC. it looked a bit less well rendered than either entropia / cryengine or second life / windlight, and ACK! the jerkiness! but... it definitely WAS visually diverse. my ideal world would be the blue mars designers working on user generated content for second life residents in a system rendered with either windlight or cryengine enabled clients. and if we do things right here... who knows... maybe something like that would happen. On Apr 13, 2009, at 6:54 AM, William George wrote: > Shows what a more advanced environment engine can provide. Anyone > seen any from Blue Mars? > > http://planetcalypso.com/news/pages/2009/04/09/7346/index.xml > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox --Apple-Mail-1--657072438 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable oooh.. john bates is gonna hate = me for saying this... but...

fwiw... i think we're = all (all of us who make virtual worlds) in an era where photorealistic = rendering is more or less cheap and readily assessable. the thing i = noticed when following john in world was that virtually _all_ the plants = looked identical. we sometimes get the same effect in second life when = you build an area with a limited number of "stock" shapes / textures. in = SL, there's a tradeoff between texture load time and visual diversity. = on one hand you could have every virtual object have it's own shape / = prim, and every prim have it's own texture. this would enhance visual = diversity. but it would probably be dog slow to load and who knows... = you might even make low-end systems with not quite enough texture memory = barf. on the other, you could have a set of stock shapes / texture and = reuse them. this would load quicker, but it would be a challenge to make = it visually appealing. i don't know that it would be impossible, only = that it would be difficult. and... different people have a different = idea for what "visually appealing" means to = them.

so... i finally saw a blue mars demo at = GDC. it looked a bit less well rendered than either entropia / cryengine = or second life / windlight, and ACK! the jerkiness! but... it definitely = WAS visually diverse. my ideal world would be the blue mars designers = working on user generated content for second life residents in a system = rendered with either windlight or cryengine enabled = clients.

and if we do things right here... who = knows... maybe something like that would = happen.

On Apr 13, 2009, at 6:54 AM, William = George wrote:

Shows what a more advanced environment engine can provide. = Anyone seen any from Blue Mars?

htt= p://planetcalypso.com/news/pages/2009/04/09/7346/index.xml
=

_______________________________________________
mmox mailing = list
mmox@ietf.org
https://www.ietf.org/ma= ilman/listinfo/mmox

= --Apple-Mail-1--657072438-- From jwatte@gmail.com Mon Apr 13 15:52:40 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CDA83A6EDB for ; Mon, 13 Apr 2009 15:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.801 X-Spam-Level: X-Spam-Status: No, score=-1.801 tagged_above=-999 required=5 tests=[AWL=-0.691, BAYES_05=-1.11] 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 z6HRaAPWYy8p for ; Mon, 13 Apr 2009 15:52:39 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id 065E83A6EDA for ; Mon, 13 Apr 2009 15:52:39 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1858688rvf.5 for ; Mon, 13 Apr 2009 15:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=sHyUp0LKBFBjCgUNdC6iHU4AqG1s5YFnC7kmhud+Bo8=; b=Do1ySD0KYjVsmDZb3lo2chf7qzziDCg6slwxfj92+lj6X42AEDm1OB/ve/N71Vw72j VX7yGJDi+vVMotscl+V++RpKANdsejSt2028G+Psnl5CHK45FgtebSYMB4iYCIdQfsS6 2keknaX/85x60ZzE72STJVseRSBc9KsxN/kLg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Jm7xc84dmklu93tZ341gcyVHlSF+XPchjq/UxlDvYIEVxbfELCckENOlwqxCAwkVKe sKUGU+Mv32j7jTAgOOZtgoeAYYmpq9UGhvLnlQNvzR71JtLP6k+xYGtaf32A3Xv1uYYW xhvzjPz09rzATitKPpXh9kM/mlc9z4hbns8hE= Received: by 10.141.197.14 with SMTP id z14mr2934748rvp.203.1239663230097; Mon, 13 Apr 2009 15:53:50 -0700 (PDT) Received: from ?10.10.111.233? (smtp.forterrainc.com [208.64.184.34]) by mx.google.com with ESMTPS id b8sm13087920rvf.52.2009.04.13.15.53.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 13 Apr 2009 15:53:49 -0700 (PDT) Message-ID: <49E3C27C.70005@gmail.com> Date: Mon, 13 Apr 2009 15:53:48 -0700 From: Jon Watte User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: William George References: <27a487810904130654n3d8e69abye1c6c98c18a147a9@mail.gmail.com> In-Reply-To: <27a487810904130654n3d8e69abye1c6c98c18a147a9@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org Subject: Re: [mmox] Cryengine 2 screenshots from Extropia X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 22:52:40 -0000 Blue Mars looks fantastic. Of course, they are cutting out pretty much their entire addressable market by requiring a GeForce 9800 or higher to run... I think that mass products like the bigger MMOs and VWs are actually not friends of the graphics vendors, because the big trend is towards cheaper rendering, to be able to address more consumers. You may think that a $300 graphics card is dirt cheap and well worth it, but the average consumer couldn't care less -- he'd rather make an additional car payment, and stay with Intel GMA graphics. Sincerely, jw William George wrote: > Shows what a more advanced environment engine can provide. Anyone seen > any from Blue Mars? > > http://planetcalypso.com/news/pages/2009/04/09/7346/index.xml > > > ------------------------------------------------------------------------ > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From wjgeorge@dceo.rutgers.edu Tue Apr 14 07:10:19 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EFFD3A6DA2 for ; Tue, 14 Apr 2009 07:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.397 X-Spam-Level: X-Spam-Status: No, score=-0.397 tagged_above=-999 required=5 tests=[AWL=-1.021, BAYES_50=0.001, 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 g43vquSdXJyP for ; Tue, 14 Apr 2009 07:10:17 -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 7183A3A6C69 for ; Tue, 14 Apr 2009 07:10:17 -0700 (PDT) Received: by yx-out-2324.google.com with SMTP id 8so3489987yxm.49 for ; Tue, 14 Apr 2009 07:11:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.108.2 with SMTP id g2mr10275318anc.86.1239718283743; Tue, 14 Apr 2009 07:11:23 -0700 (PDT) In-Reply-To: <49E3C27C.70005@gmail.com> References: <27a487810904130654n3d8e69abye1c6c98c18a147a9@mail.gmail.com> <49E3C27C.70005@gmail.com> Date: Tue, 14 Apr 2009 10:11:23 -0400 Message-ID: <27a487810904140711h266b5a40w97f62f55222ead77@mail.gmail.com> From: William George To: Jon Watte Content-Type: multipart/alternative; boundary=0016e64402a0ee6e2d04678467e3 Cc: mmox@ietf.org Subject: Re: [mmox] Cryengine 2 screenshots from Extropia X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 14:10:19 -0000 --0016e64402a0ee6e2d04678467e3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit You might want to check prices on that. I have a 9800 gtx+ I purchased (without much shopping) for $160. I agree with your statements about the average consumer, but I also feel that that Intel chip is way underpowered. I've heard that the Nvidia ION chipset will be a more powerful alternative I also noticed that Blue Mars is requiring Vista waka On Mon, Apr 13, 2009 at 6:53 PM, Jon Watte wrote: > Blue Mars looks fantastic. Of course, they are cutting out pretty much > their entire addressable market by requiring a GeForce 9800 or higher to > run... I think that mass products like the bigger MMOs and VWs are actually > not friends of the graphics vendors, because the big trend is towards > cheaper rendering, to be able to address more consumers. You may think that > a $300 graphics card is dirt cheap and well worth it, but the average > consumer couldn't care less -- he'd rather make an additional car payment, > and stay with Intel GMA graphics. > > Sincerely, > > jw > > --0016e64402a0ee6e2d04678467e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You might want to check prices on that. I have a 9800 gtx+ I purchased (wit= hout much shopping) for $160. I agree with your statements about the averag= e consumer, but I also feel that that Intel chip is way underpowered. I'= ;ve heard that the Nvidia ION chipset will be a more powerful alternative
I also noticed that Blue Mars is requiring Vista

waka

On Mon, Apr 13, 2009 at 6:53 PM, Jon Watte <jwatte@gmail.com><= /span> wrote:
Blue Mars looks f= antastic. Of course, they are cutting out pretty much their entire addressa= ble market by requiring a GeForce 9800 or higher to run... I think that mas= s products like the bigger MMOs and VWs are actually not friends of the gra= phics vendors, because the big trend is towards cheaper rendering, to be ab= le to address more consumers. You may think that a $300 graphics card is di= rt cheap and well worth it, but the average consumer couldn't care less= -- he'd rather make an additional car payment, and stay with Intel GMA= graphics.

Sincerely,

jw


--0016e64402a0ee6e2d04678467e3-- From gareth@litesim.com Tue Apr 14 07:13:01 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E17828C106 for ; Tue, 14 Apr 2009 07:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[AWL=0.005, 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 NbBeR+eZpK+M for ; Tue, 14 Apr 2009 07:12:59 -0700 (PDT) Received: from mail-bw0-f169.google.com (mail-bw0-f169.google.com [209.85.218.169]) by core3.amsl.com (Postfix) with ESMTP id 5DE2728C119 for ; Tue, 14 Apr 2009 07:12:59 -0700 (PDT) Received: by bwz17 with SMTP id 17so2452789bwz.37 for ; Tue, 14 Apr 2009 07:14:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.228.7 with SMTP id f7mr3980531mur.0.1239718449981; Tue, 14 Apr 2009 07:14:09 -0700 (PDT) In-Reply-To: <49E3C27C.70005@gmail.com> References: <27a487810904130654n3d8e69abye1c6c98c18a147a9@mail.gmail.com> <49E3C27C.70005@gmail.com> Date: Tue, 14 Apr 2009 15:14:09 +0100 Message-ID: <61dbdd7d0904140714n65af83dbue8fa6b9461ee0bb6@mail.gmail.com> From: Gareth Nelson To: Jon Watte Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mmox@ietf.org, William George Subject: Re: [mmox] Cryengine 2 screenshots from Extropia X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 14:13:01 -0000 Ultimately, graphical rendering should be based upon graceful degradation, so that lower-powered hardware simply shows the graphics at lower quality. SL has this to an extent, and the web has had it from the start. More to the point, aren't we here to work on such protocols? On Mon, Apr 13, 2009 at 11:53 PM, Jon Watte wrote: > Blue Mars looks fantastic. Of course, they are cutting out pretty much their > entire addressable market by requiring a GeForce 9800 or higher to run... I > think that mass products like the bigger MMOs and VWs are actually not > friends of the graphics vendors, because the big trend is towards cheaper > rendering, to be able to address more consumers. You may think that a $300 > graphics card is dirt cheap and well worth it, but the average consumer > couldn't care less -- he'd rather make an additional car payment, and stay > with Intel GMA graphics. > > Sincerely, > > jw > > > William George wrote: >> >> Shows what a more advanced environment engine can provide. Anyone seen any >> from Blue Mars? >> >> http://planetcalypso.com/news/pages/2009/04/09/7346/index.xml >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> mmox mailing list >> mmox@ietf.org >> https://www.ietf.org/mailman/listinfo/mmox >> > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > From infinity@lindenlab.com Tue Apr 14 08:49:10 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 076353A6E20 for ; Tue, 14 Apr 2009 08:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2yA99hI7-Dv for ; Tue, 14 Apr 2009 08:49:08 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id 352E43A6E28 for ; Tue, 14 Apr 2009 08:49:06 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id k40so2279664rvb.49 for ; Tue, 14 Apr 2009 08:50:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.137.16 with SMTP id p16mr3243238rvn.200.1239724217806; Tue, 14 Apr 2009 08:50:17 -0700 (PDT) In-Reply-To: <61dbdd7d0904140714n65af83dbue8fa6b9461ee0bb6@mail.gmail.com> References: <27a487810904130654n3d8e69abye1c6c98c18a147a9@mail.gmail.com> <49E3C27C.70005@gmail.com> <61dbdd7d0904140714n65af83dbue8fa6b9461ee0bb6@mail.gmail.com> Date: Tue, 14 Apr 2009 08:50:17 -0700 Message-ID: <3a880e2c0904140850u76a494bcj11b9f3525871a93c@mail.gmail.com> From: Infinity Linden To: Gareth Nelson Content-Type: multipart/alternative; boundary=000e0cd212cc9f41ba046785c914 Cc: mmox@ietf.org, Jon Watte , William George Subject: Re: [mmox] Cryengine 2 screenshots from Extropia X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 15:49:10 -0000 --000e0cd212cc9f41ba046785c914 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit yup. that's what i'm hoping. personally... i'm thinking rendering issues are sorta out of scope. but that last statement comes with the big "HOWEVER"... we totally DO NOT want to specify a wire protocol that makes any kind of rendering difficult. and it's a popular thing for protocol designers to make assumptions about what participants are going to do with the protocol they consume. which is probably why there's such talk of people saying... "oh! we should support meshes!" and "oh! we should support NURBS!" and ... -cheers On Tue, Apr 14, 2009 at 7:14 AM, Gareth Nelson wrote: > Ultimately, graphical rendering should be based upon graceful > degradation, so that lower-powered hardware simply shows the graphics > at lower quality. > > SL has this to an extent, and the web has had it from the start. > > More to the point, aren't we here to work on such protocols? > > On Mon, Apr 13, 2009 at 11:53 PM, Jon Watte wrote: > > Blue Mars looks fantastic. Of course, they are cutting out pretty much > their > > entire addressable market by requiring a GeForce 9800 or higher to run... > I > > think that mass products like the bigger MMOs and VWs are actually not > > friends of the graphics vendors, because the big trend is towards cheaper > > rendering, to be able to address more consumers. You may think that a > $300 > > graphics card is dirt cheap and well worth it, but the average consumer > > couldn't care less -- he'd rather make an additional car payment, and > stay > > with Intel GMA graphics. > > > > Sincerely, > > > > jw > > > > > > William George wrote: > >> > >> Shows what a more advanced environment engine can provide. Anyone seen > any > >> from Blue Mars? > >> > >> http://planetcalypso.com/news/pages/2009/04/09/7346/index.xml > >> > >> > >> ------------------------------------------------------------------------ > >> > >> _______________________________________________ > >> mmox mailing list > >> mmox@ietf.org > >> https://www.ietf.org/mailman/listinfo/mmox > >> > > > > _______________________________________________ > > mmox mailing list > > mmox@ietf.org > > https://www.ietf.org/mailman/listinfo/mmox > > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox > --000e0cd212cc9f41ba046785c914 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable yup. that's what i'm hoping.

personally... i'= ;m thinking rendering issues are sorta out of scope.

but that last statement comes with the big "HOWEVER"... we tot= ally DO NOT want to specify a wire protocol that makes any kind of renderin= g difficult. and it's a popular thing for protocol designers to make as= sumptions about what participants are going to do with the protocol they co= nsume.

which is probably why there's such talk of people s= aying... "oh! we should support meshes!" and "oh! we should = support NURBS!" and ...

-cheers

On Tue, Apr 14, 2009 at 7:14 AM, Gareth Nels= on <gareth@lites= im.com> wrote:
Ultimately, graphical rendering should be based upon graceful
degradation, so that lower-powered hardware simply shows the graphics
at lower quality.

SL has this to an extent, and the web has had it from the start.

More to the point, aren't we here to work on such protocols?

On Mon, Apr 13, 2009 at 11:53 PM, Jon Watte <jwatte@gmail.com> wrote:
> Blue Mars looks fantastic. Of course, they are cutting out pretty much= their
> entire addressable market by requiring a GeForce 9800 or higher to run= ... I
> think that mass products like the bigger MMOs and VWs are actually not=
> friends of the graphics vendors, because the big trend is towards chea= per
> rendering, to be able to address more consumers. You may think that a = $300
> graphics card is dirt cheap and well worth it, but the average consume= r
> couldn't care less -- he'd rather make an additional car payme= nt, and stay
> with Intel GMA graphics.
>
> Sincerely,
>
> jw
>
>
> William George wrote:
>>
>> Shows what a more advanced environment engine can provide. Anyone = seen any
>> from Blue Mars?
>>
>> http://planetcalypso.com/news/pages/2009/04/09/73= 46/index.xml
>>
>>
>> ------------------------------------------------------------------= ------
>>
>> _______________________________________________
>> mmox mailing list
>> mmox@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmox
>>
>
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox
>
_______________________________________________
mmox mailing list
mmox@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mmox

--000e0cd212cc9f41ba046785c914-- From john.hurliman@intel.com Tue Apr 14 10:14:02 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C9713A6E33 for ; Tue, 14 Apr 2009 10:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.557 X-Spam-Level: X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 gf9fgUP3paKs for ; Tue, 14 Apr 2009 10:14:01 -0700 (PDT) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by core3.amsl.com (Postfix) with ESMTP id 722153A68B0 for ; Tue, 14 Apr 2009 10:14:01 -0700 (PDT) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 14 Apr 2009 10:15:13 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.40,186,1239001200"; d="scan'208";a="131360928" Received: from rrsmsx604.amr.corp.intel.com ([10.31.0.170]) by azsmga001.ch.intel.com with ESMTP; 14 Apr 2009 10:15:12 -0700 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx604.amr.corp.intel.com ([10.31.0.170]) with mapi; Tue, 14 Apr 2009 11:14:31 -0600 From: "Hurliman, John" To: Infinity Linden , Gareth Nelson Date: Tue, 14 Apr 2009 11:14:28 -0600 Thread-Topic: [mmox] Cryengine 2 screenshots from Extropia Thread-Index: Acm9GMH0/qgz4zKLTY6pea105aJR+wAC0XLQ Message-ID: <62BFE5680C037E4DA0B0A08946C0933D7BAAC919@rrsmsx506.amr.corp.intel.com> References: <27a487810904130654n3d8e69abye1c6c98c18a147a9@mail.gmail.com> <49E3C27C.70005@gmail.com> <61dbdd7d0904140714n65af83dbue8fa6b9461ee0bb6@mail.gmail.com> <3a880e2c0904140850u76a494bcj11b9f3525871a93c@mail.gmail.com> In-Reply-To: <3a880e2c0904140850u76a494bcj11b9f3525871a93c@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: William, Jon Watte , "mmox@ietf.org" , George Subject: Re: [mmox] Cryengine 2 screenshots from Extropia X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 17:14:02 -0000 >-----Original Message----- >From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of >Infinity Linden >Sent: Tuesday, April 14, 2009 8:50 AM >To: Gareth Nelson >Cc: mmox@ietf.org; Jon Watte; William George >Subject: Re: [mmox] Cryengine 2 screenshots from Extropia > >yup. that's what i'm hoping. > >personally... i'm thinking rendering issues are sorta out of scope. > >but that last statement comes with the big "HOWEVER"... we totally DO >NOT want to specify a wire protocol that makes any kind of rendering >difficult. and it's a popular thing for protocol designers to make >assumptions about what participants are going to do with the protocol >they consume. > >which is probably why there's such talk of people saying... "oh! we >should support meshes!" and "oh! we should support NURBS!" and ... > >-cheers > It could also mean that some people are confused about the scope of the MMO= X work or the roadmap to complete the scope. If someone didn't know better = and simply visited the MmoxCharter page at http://trac.tools.ietf.org/bof/t= rac/wiki/MmoxCharter and saw "February 2010 Progression of OGP Virtual Worl= d Primitive Object Format to Proposed Standard" on the roadmap, they might = think that defining a transport format for 3D virtual world content was on = topic. John From gareth@litesim.com Tue Apr 14 10:57:33 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1A013A6952 for ; Tue, 14 Apr 2009 10:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[AWL=0.005, 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 3SYz2OqcfBkR for ; Tue, 14 Apr 2009 10:57:33 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by core3.amsl.com (Postfix) with ESMTP id A98B13A6840 for ; Tue, 14 Apr 2009 10:57:32 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 18so1179981fkq.5 for ; Tue, 14 Apr 2009 10:58:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.171.6 with SMTP id y6mr4123029muo.31.1239731923536; Tue, 14 Apr 2009 10:58:43 -0700 (PDT) In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D7BAAC919@rrsmsx506.amr.corp.intel.com> References: <27a487810904130654n3d8e69abye1c6c98c18a147a9@mail.gmail.com> <49E3C27C.70005@gmail.com> <61dbdd7d0904140714n65af83dbue8fa6b9461ee0bb6@mail.gmail.com> <3a880e2c0904140850u76a494bcj11b9f3525871a93c@mail.gmail.com> <62BFE5680C037E4DA0B0A08946C0933D7BAAC919@rrsmsx506.amr.corp.intel.com> Date: Tue, 14 Apr 2009 18:58:43 +0100 Message-ID: <61dbdd7d0904141058y298cc2e3o3066d7b6777d2ca1@mail.gmail.com> From: Gareth Nelson To: "Hurliman, John" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Jon Watte , "mmox@ietf.org" , William George Subject: Re: [mmox] Cryengine 2 screenshots from Extropia X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 17:57:33 -0000 Which is why that needs sorting out - can someone with the correct access please update that page? On Tue, Apr 14, 2009 at 6:14 PM, Hurliman, John w= rote: >>-----Original Message----- >>From: mmox-bounces@ietf.org [mailto:mmox-bounces@ietf.org] On Behalf Of >>Infinity Linden >>Sent: Tuesday, April 14, 2009 8:50 AM >>To: Gareth Nelson >>Cc: mmox@ietf.org; Jon Watte; William George >>Subject: Re: [mmox] Cryengine 2 screenshots from Extropia >> >>yup. that's what i'm hoping. >> >>personally... i'm thinking rendering issues are sorta out of scope. >> >>but that last statement comes with the big "HOWEVER"... we totally DO >>NOT want to specify a wire protocol that makes any kind of rendering >>difficult. and it's a popular thing for protocol designers to make >>assumptions about what participants are going to do with the protocol >>they consume. >> >>which is probably why there's such talk of people saying... "oh! we >>should support meshes!" and "oh! we should support NURBS!" and ... >> >>-cheers >> > > It could also mean that some people are confused about the scope of the M= MOX work or the roadmap to complete the scope. If someone didn't know bette= r and simply visited the MmoxCharter page at http://trac.tools.ietf.org/bof= /trac/wiki/MmoxCharter and saw "February 2010 Progression of OGP Virtual Wo= rld Primitive Object Format to Proposed Standard" on the roadmap, they migh= t think that defining a transport format for 3D virtual world content was o= n topic. > > John > From john.hurliman@intel.com Thu Apr 16 16:21:07 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73B633A67C0 for ; Thu, 16 Apr 2009 16:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.428 X-Spam-Level: X-Spam-Status: No, score=-6.428 tagged_above=-999 required=5 tests=[AWL=0.171, 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 eZLwKYlHZ8jP for ; Thu, 16 Apr 2009 16:21:06 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by core3.amsl.com (Postfix) with ESMTP id E5EB628C1BD for ; Thu, 16 Apr 2009 16:20:55 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 16 Apr 2009 16:12:58 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.40,200,1239001200"; d="scan'208";a="507156399" Received: from rrsmsx604.amr.corp.intel.com ([10.31.0.170]) by orsmga001.jf.intel.com with ESMTP; 16 Apr 2009 16:21:33 -0700 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx604.amr.corp.intel.com ([10.31.0.170]) with mapi; Thu, 16 Apr 2009 17:22:08 -0600 From: "Hurliman, John" To: "mmox@ietf.org" Date: Thu, 16 Apr 2009 17:22:06 -0600 Thread-Topic: Capabilities Draft Thread-Index: Acm+6ihVj/JiVuERQK2icJjQ/NykrA== Message-ID: <62BFE5680C037E4DA0B0A08946C0933D7BB49F86@rrsmsx506.amr.corp.intel.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mmox] Capabilities Draft X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 23:21:07 -0000 Has an I-D been submitted that describes Linden Lab capabilities (temporary= , difficult to guess URLs that provide access to a service)? John From infinity@lindenlab.com Thu Apr 16 16:53:16 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 842FB3A6D44 for ; Thu, 16 Apr 2009 16:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhiuDttTLioy for ; Thu, 16 Apr 2009 16:53:15 -0700 (PDT) Received: from mail-qy0-f136.google.com (mail-qy0-f136.google.com [209.85.221.136]) by core3.amsl.com (Postfix) with ESMTP id A85C63A6D34 for ; Thu, 16 Apr 2009 16:53:15 -0700 (PDT) Received: by qyk42 with SMTP id 42so188729qyk.29 for ; Thu, 16 Apr 2009 16:54:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.53.210 with SMTP id n18mr2600825qag.129.1239926068636; Thu, 16 Apr 2009 16:54:28 -0700 (PDT) In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D7BB49F86@rrsmsx506.amr.corp.intel.com> References: <62BFE5680C037E4DA0B0A08946C0933D7BB49F86@rrsmsx506.amr.corp.intel.com> Date: Thu, 16 Apr 2009 16:54:28 -0700 Message-ID: <3a880e2c0904161654t47ceaaa6l3086054f6fc55c63@mail.gmail.com> From: Infinity Linden To: "Hurliman, John" Content-Type: multipart/alternative; boundary=0015175cde32de6dae0467b4c804 Cc: "mmox@ietf.org" Subject: Re: [mmox] Capabilities Draft X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 23:53:16 -0000 --0015175cde32de6dae0467b4c804 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit the OGP Base draft zero published has a section on caps. http://tools.ietf.org/html/draft-lentczner-ogp-base-00#section-2.3 --0015175cde32de6dae0467b4c804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
the OGP Base draft zero published has a section on caps.

--0015175cde32de6dae0467b4c804-- From john.hurliman@intel.com Fri Apr 24 13:07:17 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 044CE28C32B for ; Fri, 24 Apr 2009 13:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 YHyK5fXeQagp for ; Fri, 24 Apr 2009 13:07:16 -0700 (PDT) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by core3.amsl.com (Postfix) with ESMTP id 70B0428C73E for ; Fri, 24 Apr 2009 13:07:03 -0700 (PDT) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 24 Apr 2009 13:08:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.40,243,1239001200"; d="scan'208";a="135648039" Received: from rrsmsx603.amr.corp.intel.com ([10.31.0.57]) by azsmga001.ch.intel.com with ESMTP; 24 Apr 2009 13:08:21 -0700 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx603.amr.corp.intel.com ([10.31.0.57]) with mapi; Fri, 24 Apr 2009 14:08:21 -0600 From: "Hurliman, John" To: "mmox@ietf.org" Date: Fri, 24 Apr 2009 14:08:14 -0600 Thread-Topic: PHP implementation of LLSD? Thread-Index: AcnFGGZYhKPmkSCUSduO8bKgm4MM7A== Message-ID: <62BFE5680C037E4DA0B0A08946C0933D7F7A3F31@rrsmsx506.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {A744ADBC-5BE2-4802-86DB-409E1DFB7C80} x-cr-hashedpuzzle: ABPV Bz8z CtMI C5vB FE++ Ffjs GLUg GgS8 GhVg HJbO HUyJ HvAC J5zI KUl/ Kj+q LIG0; 1; bQBtAG8AeABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {A744ADBC-5BE2-4802-86DB-409E1DFB7C80}; agBvAGgAbgAuAGgAdQByAGwAaQBtAGEAbgBAAGkAbgB0AGUAbAAuAGMAbwBtAA==; Fri, 24 Apr 2009 20:08:14 GMT; UABIAFAAIABpAG0AcABsAGUAbQBlAG4AdABhAHQAaQBvAG4AIABvAGYAIABMAEwAUwBEAD8A acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mmox] PHP implementation of LLSD? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 20:07:17 -0000 Is there a PHP implementation of LLSD available? John From gareth@litesim.com Fri Apr 24 13:30:15 2009 Return-Path: X-Original-To: mmox@core3.amsl.com Delivered-To: mmox@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E965D28C752 for ; Fri, 24 Apr 2009 13:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[AWL=0.005, 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 BlORSWeMla6K for ; Fri, 24 Apr 2009 13:30:15 -0700 (PDT) Received: from mail-bw0-f163.google.com (mail-bw0-f163.google.com [209.85.218.163]) by core3.amsl.com (Postfix) with ESMTP id 0762F28C758 for ; Fri, 24 Apr 2009 13:30:14 -0700 (PDT) Received: by bwz7 with SMTP id 7so1290178bwz.37 for ; Fri, 24 Apr 2009 13:31:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.114.136 with SMTP id e8mr2403276bkq.190.1240605091644; Fri, 24 Apr 2009 13:31:31 -0700 (PDT) In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D7F7A3F31@rrsmsx506.amr.corp.intel.com> References: <62BFE5680C037E4DA0B0A08946C0933D7F7A3F31@rrsmsx506.amr.corp.intel.com> Date: Fri, 24 Apr 2009 21:31:31 +0100 Message-ID: <61dbdd7d0904241331t76b702a6scb9e2ae287627aa@mail.gmail.com> From: Gareth Nelson To: "Hurliman, John" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "mmox@ietf.org" Subject: Re: [mmox] PHP implementation of LLSD? X-BeenThere: mmox@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Massively Multi-participant Online Games and Applications List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 20:30:16 -0000 Look into the RegAPI samples, that's where I got the python implementation from On Fri, Apr 24, 2009 at 9:08 PM, Hurliman, John wrote: > Is there a PHP implementation of LLSD available? > > John > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox >