From root@core3.amsl.com Mon Jul 5 02:15:02 2010 Return-Path: X-Original-To: vwrap@ietf.org Delivered-To: vwrap@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 377AC3A690A; Mon, 5 Jul 2010 02:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100705091502.377AC3A690A@core3.amsl.com> Date: Mon, 5 Jul 2010 02:15:02 -0700 (PDT) X-Mailman-Approved-At: Mon, 05 Jul 2010 05:58:55 -0700 Cc: vwrap@ietf.org Subject: [vwrap] I-D Action:draft-ietf-vwrap-intro-00.txt X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 09:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Virtual World Region Agent Protocol Working Group of the IETF. Title : VWRAP: Introduction and Goals Author(s) : M. Hamrick, D. Levine Filename : draft-ietf-vwrap-intro-00.txt Pages : 33 Date : 2010-07-05 The Virtual World Region Agent Protocol (VWRAP) defines interactions between hosts collaborating to create an shared, internet scale virtual world experience. This document introduces the protocol, the objectives and requirements it imposes on hosts implementing the protocol. To the extent it affects protocol interactions, this document describes the model assumed by the protocol. A document roadmap is included that briefly describes the contents of other documents produced by the VWRAP Working Group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-vwrap-intro-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-vwrap-intro-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-05021211.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 5 15:00:02 2010 Return-Path: X-Original-To: vwrap@ietf.org Delivered-To: vwrap@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 03A783A6A10; Mon, 5 Jul 2010 15:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100705220002.03A783A6A10@core3.amsl.com> Date: Mon, 5 Jul 2010 15:00:02 -0700 (PDT) Cc: vwrap@ietf.org Subject: [vwrap] I-D Action:draft-ietf-vwrap-launch-00.txt X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 22:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Virtual World Region Agent Protocol Working Group of the IETF. Title : Virtual World Region Agent Protocol : Client Application Launch Message Author(s) : M. Hamrick, J. Hurliman Filename : draft-ietf-vwrap-launch-00.txt Pages : 12 Date : 2010-07-05 This document describes the LLIDL interface description for the Virtual World Region Agent Protocol (VWRAP) Client Application Launch message format. Messages in this format are intended to be used in conjunction with standard web authentication or authorization technologies such as OpenID or OAuth. This document describes the message format, the processing expectations and three MIME types that may be used to identify requests to initiate a virtual worlds session. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-vwrap-launch-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-vwrap-launch-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-05144621.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 5 15:00:02 2010 Return-Path: X-Original-To: vwrap@ietf.org Delivered-To: vwrap@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0D0DE3A6A15; Mon, 5 Jul 2010 15:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100705220002.0D0DE3A6A15@core3.amsl.com> Date: Mon, 5 Jul 2010 15:00:02 -0700 (PDT) Cc: vwrap@ietf.org Subject: [vwrap] I-D Action:draft-ietf-vwrap-authentication-00.txt X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 22:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Virtual World Region Agent Protocol Working Group of the IETF. Title : VWRAP Trust Model and User Authentication Author(s) : T. Chu, et al. Filename : draft-ietf-vwrap-authentication-00.txt Pages : 16 Date : 2010-07-05 Authentication in the Virtual World Region Agent Protocol establishes an application layer association between a client application and a remote service responsible for managing the end user's identity. The objective of authentication is to verify the user of a client application possesses appropriate credentials before granting capabilities sufficient to assert control over the user's agent and digital assets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-vwrap-authentication-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-vwrap-authentication-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-05144631.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 5 15:15:06 2010 Return-Path: X-Original-To: vwrap@ietf.org Delivered-To: vwrap@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 65A533A6A10; Mon, 5 Jul 2010 15:15:05 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100705221506.65A533A6A10@core3.amsl.com> Date: Mon, 5 Jul 2010 15:15:05 -0700 (PDT) Cc: vwrap@ietf.org Subject: [vwrap] I-D Action:draft-ietf-vwrap-type-system-00.txt X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 22:15:06 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Virtual World Region Agent Protocol Working Group of the IETF. Title : VWRAP : Abstract Type System for the Transmission of Dynamic Structured Data Author(s) : M. Hamrick Filename : draft-ietf-vwrap-type-system-00.txt Pages : 40 Date : 2010-07-05 This document describes the LLIDL interface description language, the related LLSD abstract type system and three serialization formats for LLIDL messages. LLIDL (pronounced "little") is a language-neutral facility for describing transport independent message flows for RESTful resource access. LLIDL itself is an abstract meta-grammar for producing and recognizing valid request / response messages affecting state change in application layer objects by way of RESTful resource access. It may be used by protocol developers and system deployers to describe the composition of application layer protocol exchanges without adopting transport specific message semantics or programming language specific type semantics. The type behavior of individual message elements is described by the LLSD abstract type system. Abstract LLIDL messages are concretized using one of three defined LLSD serialization schemes. Serialization / deserialization rules are provided in this document for XML, JSON and Binary schemes. This abstract messaging and type system is intended to be used by other specifications to describe application layer protocol exchanges, independent of implementation language or message transport protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-vwrap-type-system-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-vwrap-type-system-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-05150959.I-D@ietf.org> --NextPart-- From ohmeadhbh@gmail.com Mon Jul 5 15:28:59 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD3E13A6966 for ; Mon, 5 Jul 2010 15:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+XnWVDg5DzV for ; Mon, 5 Jul 2010 15:28:58 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 8F0293A691D for ; Mon, 5 Jul 2010 15:28:55 -0700 (PDT) Received: by vws14 with SMTP id 14so5148173vws.31 for ; Mon, 05 Jul 2010 15:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=OYy8vqk4NIUP7qmIYlw4ZQD3zPIzq3jp/5Hn7aUI3qc=; b=Pzyz0wCg+YAIQrECvC+zCKjYcnKtZHsMI/sCIpvQ99x7RrOJ15Jv1ze8pcQKY7xxtC E1paVUYYhrwlHuhMqXMoVhPL5CRUHTYHpQwwLi28s1qd8+YFmHOrgFfXipKkjm4E8Bla oXjbh53X02Hodbb1CJtMn7haSIMGi9YFYZn6E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=MAJE8MTCmRR3VtmfOA+GruM6RcYnGh2/ZT66np7FcDqXXivm5SGlyb/jb5MzbsDIHW KLfPVsL4jFweF7JeWgpTP0FBTYwSpiPijaruA/WxMs6NwoT6Ff+J3zHzyHtziFRrB3xc LO9yiiFIIgxrbrxDqCeuAfQGgaSAr1ZzMIhKk= Received: by 10.229.99.85 with SMTP id t21mr1993673qcn.260.1278368932282; Mon, 05 Jul 2010 15:28:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.185.73 with HTTP; Mon, 5 Jul 2010 15:28:32 -0700 (PDT) From: Meadhbh Hamrick Date: Mon, 5 Jul 2010 15:28:32 -0700 Message-ID: To: vwrap@ietf.org, opensource-dev@lists.secondlife.com Content-Type: text/plain; charset=ISO-8859-1 Subject: [vwrap] New Revisions of VWRAP Internet Drafts Published X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 22:29:00 -0000 from http://blog.meadhbh.org/2010/07/new-vwrap-internet-drafts-published.html : hey peeps! this is just a quick note to let you know that i just pushed out several new versions of the following VWRAP Internet Drafts: VWRAP : Introduction and Goals https://datatracker.ietf.org/doc/draft-ietf-vwrap-intro/ this is the draft that's intended to be a "gentle introduction" to our kind of virtual world, the protocol and the documents. i believe it is "very close" to being fully baked. based on feedback from the mailing list and face to face meetings, i added a section on deployment patterns (without using the terms "Second Life" or "OpenSim",) removed the archaic concepts of agent and region domains, added a document roadmap and added a few terms in the glossary. also, i fixed up the references in the back so they *should* be pointing to the most recent revisions of things. VWRAP : Abstract Type System for the Transmission of Dynamic Structured Data https://datatracker.ietf.org/doc/draft-ietf-vwrap-type-system/ this one still needs a little bit of work and is essentially the same as the version published last february. however, we seemed to be hurtling towards consensus on this one. VWRAP : Trust Model and User Authentication https://datatracker.ietf.org/doc/draft-ietf-vwrap-authentication/ i added references to the CALM draft, and removed the legacy bit about agent id's. it's now all account ids, which is what i think we all said we wanted. MD5 is still in the draft 'cause i wasn't completely sure we all agreed to remove it. i need to add some more verbiage about the "trust model," and possibly remove the MD5 references if that's what the working group wants to do. VWRAP : Client Application Launch Message https://datatracker.ietf.org/doc/draft-ietf-vwrap-launch/ this is the draft that describes how we send a message from a web site to the viewer to launch the viewer. it's intended to support web-based auth schemes like OpenID and OAuth. i added a little more verbiage regarding the use of a web capability as the location for an agent_login resource and tried to make sure the references were pointing to the right place. so... i encourage everyone to take a look at these docs and let me know if you see anything wrong with them. cheers! meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com From root@core3.amsl.com Mon Jul 5 17:45:02 2010 Return-Path: X-Original-To: vwrap@ietf.org Delivered-To: vwrap@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7C6C13A6890; Mon, 5 Jul 2010 17:45:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100706004502.7C6C13A6890@core3.amsl.com> Date: Mon, 5 Jul 2010 17:45:02 -0700 (PDT) Cc: vwrap@ietf.org Subject: [vwrap] I-D Action:draft-ietf-vwrap-foundation-00.txt X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 00:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Virtual World Region Agent Protocol Working Group of the IETF. Title : Virtual World Region Agent Protocol: Foundation Author(s) : M. Lentczner, M. Hamrick Filename : draft-ietf-vwrap-foundation-00.txt Pages : 13 Date : 2010-07-05 The Virtual World Region Agent Protocol documents define the protocols by which a vast, Internet wide virtual world can operate. This protocol enables different regions of the virtual world to be operated independently, yet interoperate to form a cohesive experience. This document specifies the foundation upon which various suites of virtual world functionality are built. It describes the basic structure of VWRAP interaction and common methodology and terminology for protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-vwrap-foundation-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-vwrap-foundation-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-05173657.I-D@ietf.org> --NextPart-- From stpeter@stpeter.im Tue Jul 6 09:06:58 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2022C3A6828 for ; Tue, 6 Jul 2010 09:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxdvqNtp8zLh for ; Tue, 6 Jul 2010 09:06:56 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 615153A680D for ; Tue, 6 Jul 2010 09:06:56 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3992140E36 for ; Tue, 6 Jul 2010 10:06:58 -0600 (MDT) Message-ID: <4C3354A0.2070304@stpeter.im> Date: Tue, 06 Jul 2010 10:06:56 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: vwrap@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040501040706000207080404" Subject: Re: [vwrap] New Revisions of VWRAP Internet Drafts Published X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 16:06:58 -0000 This is a cryptographically signed message in MIME format. --------------ms040501040706000207080404 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks, Meadhbh! It's great to see that you're still actively engaged with this work. Now let's get some folks on the list to provide comments.= :) On 7/5/10 4:28 PM, Meadhbh Hamrick wrote: > from http://blog.meadhbh.org/2010/07/new-vwrap-internet-drafts-publishe= d.html : >=20 > hey peeps! this is just a quick note to let you know that i just > pushed out several new versions of the following VWRAP Internet > Drafts: >=20 > VWRAP : Introduction and Goals > https://datatracker.ietf.org/doc/draft-ietf-vwrap-intro/ >=20 > this is the draft that's intended to be a "gentle introduction" to our > kind of virtual world, the protocol and the documents. i believe it is > "very close" to being fully baked. based on feedback from the mailing > list and face to face meetings, i added a section on deployment > patterns (without using the terms "Second Life" or "OpenSim",) removed > the archaic concepts of agent and region domains, added a document > roadmap and added a few terms in the glossary. also, i fixed up the > references in the back so they *should* be pointing to the most recent > revisions of things. >=20 > VWRAP : Abstract Type System for the Transmission of Dynamic Structured= Data > https://datatracker.ietf.org/doc/draft-ietf-vwrap-type-system/ >=20 > this one still needs a little bit of work and is essentially the same > as the version published last february. however, we seemed to be > hurtling towards consensus on this one. >=20 > VWRAP : Trust Model and User Authentication > https://datatracker.ietf.org/doc/draft-ietf-vwrap-authentication/ >=20 > i added references to the CALM draft, and removed the legacy bit about > agent id's. it's now all account ids, which is what i think we all > said we wanted. MD5 is still in the draft 'cause i wasn't completely > sure we all agreed to remove it. i need to add some more verbiage > about the "trust model," and possibly remove the MD5 references if > that's what the working group wants to do. >=20 > VWRAP : Client Application Launch Message > https://datatracker.ietf.org/doc/draft-ietf-vwrap-launch/ >=20 > this is the draft that describes how we send a message from a web site > to the viewer to launch the viewer. it's intended to support web-based > auth schemes like OpenID and OAuth. i added a little more verbiage > regarding the use of a web capability as the location for an > agent_login resource and tried to make sure the references were > pointing to the right place. >=20 > so... i encourage everyone to take a look at these docs and let me > know if you see anything wrong with them. >=20 > cheers! > meadhbh > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap --------------ms040501040706000207080404 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDcwNjE2MDY1NlowIwYJKoZIhvcNAQkEMRYEFN4jetRjR9uxZiW7qNnb pooaZtfyMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAJPd7QpmrCWI2XfMt3ukNZ1RG1d9HET2nP0rPQCS4 yoVhyX6ObcCJl+ddN1c3Yw9FjzT75c1mtzp2iEcNKVmkBLv9JxPHGZtTXFl6R9YbEmkI8Nzx xrlvoow9Iyh8IJCzokD6nIe2jiBfzd4ra1fa/4Pjde5RiofeySToPg/lA9H1dCuwl/EYhkwB bplgrjPTcAqL5bAKZ3JZwMlQRUGtGT9DYQU4F84b2fxYcb/bErD92Cg+rJb/3NDIBz6cgxHT Nql2Pc1PvF+TrzPICrnJFdlzcTHuIqfUs8Sfv1OtHsasE4mkQmpOAPAZISWDe3TgpmZkeDDG R+d5zPeU2UISIwAAAAAAAA== --------------ms040501040706000207080404-- From john.hurliman@intel.com Tue Jul 6 10:29:43 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 850083A682B for ; Tue, 6 Jul 2010 10:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 R+9bNnvZfUiz for ; Tue, 6 Jul 2010 10:29:41 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by core3.amsl.com (Postfix) with ESMTP id 9E98E3A6844 for ; Tue, 6 Jul 2010 10:29:41 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 06 Jul 2010 10:29:05 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.53,547,1272870000"; d="scan'208";a="636111552" Received: from rrsmsx602.amr.corp.intel.com ([10.31.0.33]) by orsmga001.jf.intel.com with ESMTP; 06 Jul 2010 10:29:35 -0700 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by rrsmsx602.amr.corp.intel.com ([10.31.0.33]) with mapi; Tue, 6 Jul 2010 11:29:31 -0600 From: "Hurliman, John" To: "vwrap@ietf.org" Date: Tue, 6 Jul 2010 11:29:30 -0600 Thread-Topic: [vwrap] New Revisions of VWRAP Internet Drafts Published Thread-Index: AcsdJUZLUnmbvi0NRpeyZphK3mn7gAACaiKQ Message-ID: <62BFE5680C037E4DA0B0A08946C0933DDA75DE93@rrsmsx506.amr.corp.intel.com> References: <4C3354A0.2070304@stpeter.im> In-Reply-To: <4C3354A0.2070304@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [vwrap] New Revisions of VWRAP Internet Drafts Published X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 17:29:43 -0000 Tm93IHRoYXQgdGhlIENBTE0gZHJhZnQgaXMgYWxpdmUgYW5kIGtpY2tpbmcgYWdhaW4gbGV0J3Mg c2VlIGhvdyBJIGNhbiBicmVhayBpdCA6LSkuIE9uZSBpc3N1ZSBJIHJhbiBpbnRvIHdoaWxlIGlt cGxlbWVudGluZyBteSBsYXVuY2hlciBhcHAgd2FzIHRoZSBuZWVkIHRvIGRpc3Rpbmd1aXNoIGJl dHdlZW4gY2FwYWJpbGl0eSBsb2dpbiBVUkxzIGFuZCB1bmF1dGhlbnRpY2F0ZWQgbG9naW4gVVJM cy4gSGVyZSBhcmUgb3VyIHVzZSBjYXNlczoNCg0KYSkgQSB1c2VyIHZpc2l0cyBzY2llbmNlc2lt LmNvbSwgY3JlYXRlcyBhbiBhY2NvdW50IGFuZC9vciBsb2dzIGluLCBnb2VzIHRvIHRoZWlyIHN0 YXJ0IHBhZ2UgKGxldCdzIHNheSBzY2llbmNlc2ltLmNvbS9hY2NvdW50LykgYW5kIGNsaWNrcyBh IExhdW5jaCBidXR0b24gdGhhdCBwb2ludHMgdG8gYSBDQUxNIGRvY3VtZW50IHdpdGggYSBsb2dp biBjYXBhYmlsaXR5LiBUaGUgbGF1bmNoZXIgYXBwIGtub3dzIHRvIHN0YXJ0IHRoZSB2aWV3ZXIg aW4gInByZS1hdXRoZW50aWNhdGVkIiBtb2RlIHdoZXJlIGl0IHNraXBzIHRoZSB1c2VybmFtZS9w YXNzd29yZCBlbnRyeSBmb3JtIGFuZCB0cmllcyB0byBsb2cgZGlyZWN0bHkgaW4td29ybGQuDQoN CmIpIEEgdXNlciB3YW50cyB0byBsb2dpbiB0byBzY2llbmNlc2ltLmNvbSB1c2luZyB0aGUgdXNl cm5hbWUvcGFzc3dvcmQgZW50cnkgZm9ybSBidWlsdCBpbnRvIHRoZSB2aWV3ZXIsIHdpdGhvdXQg ZG9pbmcgYSB3ZWIgYXV0aGVudGljYXRpb24gZmlyc3QuIFRoZXkgaGF2ZSBzY2llbmNlc2ltLmNv bS9sYXVuY2gvIGJvb2ttYXJrZWQgd2hpY2ggcmV0dXJucyBhIENBTE0gZG9jdW1lbnQgY29udGFp bmluZyB0aGUgdW5hdXRoZW50aWNhdGVkIGxvZ2luIHVybCBmb3Igc2NpZW5jZXNpbS4gVGhpcyBp bnN0cnVjdHMgdGhlIGxhdW5jaGVyIHRvIG9wZW4gdGhlIHZpZXdlciBpbiAidXNlcm5hbWUvcGFz c3dvcmQgcHJvbXB0IG1vZGUiLg0KDQpUbyBhY2hpZXZlIGJvdGggb2YgdGhlc2UgdXNlIGNhc2Vz IEkgYWRkZWQgYSBuZXcgJmF1dGhlbnRpY2F0b3IgdGhhdCBjb250YWlucyB7ICJ0eXBlIjogImNh cGFiaWxpdHkiIH0gdG8gZGlzdGluZ3Vpc2ggYSBwcmUtYXV0aGVudGljYXRlZCBVUkwgZnJvbSB0 aGUgcmVndWxhciB2YXJpZXR5LiBJIGFsc28gYWRkZWQgYSBiaXQgb2YgY29kZSB0byBsb29rIGZv ciBlaXRoZXIgIm5hbWUiIG9yIG1lcmdlICJmaXJzdF9uYW1lIiArICJsYXN0X25hbWUiIGludG8g YSBOYW1lIGZpZWxkLiBUaGUgZnVsbCBDQUxNIHBhcnNpbmcgY29kZSBmb3IgdGhlIGxhdW5jaGVy IGlzIGluIFNWTiBhdCA8aHR0cDovL2NvZGUuZ29vZ2xlLmNvbS9wL29wZW5tZXRhdmVyc2Uvc291 cmNlL2Jyb3dzZS90cnVuay9MYXVuY2hlci9MYXVuY2hEb2N1bWVudC5jcz4uIFlvdSdsbCBub3Rp Y2UgYSBjb3VwbGUgb2Ygbm9uLXN0YW5kYXJkIGV4dGVuc2lvbnMgKCJ3ZWxjb21ldXJsIiwgImVj b25vbXl1cmwiLCAiYWJvdXR1cmwiLCAicmVnaXN0ZXJ1cmwiLCAiaGVscHVybCIsICJwYXNzd29y ZHVybCIpIHRoYXQgYXJlIG5vdCBwYXJ0IG9mIHRoZSBzcGVjLCBidXQgdXNlZCBpbiB0aGUgbGF1 bmNoZXIgYXBwIHNpbmNlIHdlJ3JlIHVzaW5nIENBTE0gZG9jdW1lbnRzIGFzIHRoZSBob3BlZnVs IHN1Y2Nlc3NvciB0byBHcmlkSW5mbyBkb2N1bWVudHMgKGh0dHA6Ly9vcGVuc2ltdWxhdG9yLm9y Zy93aWtpL0dyaWRJbmZvKS4NCg0KSm9obg0KDQoNCk9uIDcvNS8xMCA0OjI4IFBNLCBNZWFkaGJo IEhhbXJpY2sgd3JvdGU6DQo+IGZyb20gaHR0cDovL2Jsb2cubWVhZGhiaC5vcmcvMjAxMC8wNy9u ZXctdndyYXAtaW50ZXJuZXQtZHJhZnRzLXB1Ymxpc2hlZC5odG1sIDoNCj4gDQo+IGhleSBwZWVw cyEgdGhpcyBpcyBqdXN0IGEgcXVpY2sgbm90ZSB0byBsZXQgeW91IGtub3cgdGhhdCBpIGp1c3Qg DQo+IHB1c2hlZCBvdXQgc2V2ZXJhbCBuZXcgdmVyc2lvbnMgb2YgdGhlIGZvbGxvd2luZyBWV1JB UCBJbnRlcm5ldA0KPiBEcmFmdHM6DQo+IA0KPiBWV1JBUCA6IEludHJvZHVjdGlvbiBhbmQgR29h bHMNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12d3JhcC1p bnRyby8NCj4gDQo+IHRoaXMgaXMgdGhlIGRyYWZ0IHRoYXQncyBpbnRlbmRlZCB0byBiZSBhICJn ZW50bGUgaW50cm9kdWN0aW9uIiB0byBvdXIgDQo+IGtpbmQgb2YgdmlydHVhbCB3b3JsZCwgdGhl IHByb3RvY29sIGFuZCB0aGUgZG9jdW1lbnRzLiBpIGJlbGlldmUgaXQgaXMgDQo+ICJ2ZXJ5IGNs b3NlIiB0byBiZWluZyBmdWxseSBiYWtlZC4gYmFzZWQgb24gZmVlZGJhY2sgZnJvbSB0aGUgbWFp bGluZyANCj4gbGlzdCBhbmQgZmFjZSB0byBmYWNlIG1lZXRpbmdzLCBpIGFkZGVkIGEgc2VjdGlv biBvbiBkZXBsb3ltZW50IA0KPiBwYXR0ZXJucyAod2l0aG91dCB1c2luZyB0aGUgdGVybXMgIlNl Y29uZCBMaWZlIiBvciAiT3BlblNpbSIsKSByZW1vdmVkIA0KPiB0aGUgYXJjaGFpYyBjb25jZXB0 cyBvZiBhZ2VudCBhbmQgcmVnaW9uIGRvbWFpbnMsIGFkZGVkIGEgZG9jdW1lbnQgDQo+IHJvYWRt YXAgYW5kIGFkZGVkIGEgZmV3IHRlcm1zIGluIHRoZSBnbG9zc2FyeS4gYWxzbywgaSBmaXhlZCB1 cCB0aGUgDQo+IHJlZmVyZW5jZXMgaW4gdGhlIGJhY2sgc28gdGhleSAqc2hvdWxkKiBiZSBwb2lu dGluZyB0byB0aGUgbW9zdCByZWNlbnQgDQo+IHJldmlzaW9ucyBvZiB0aGluZ3MuDQo+IA0KPiBW V1JBUCA6IEFic3RyYWN0IFR5cGUgU3lzdGVtIGZvciB0aGUgVHJhbnNtaXNzaW9uIG9mIER5bmFt aWMgDQo+IFN0cnVjdHVyZWQgRGF0YSANCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi12d3JhcC10eXBlLXN5c3RlbS8NCj4gDQo+IHRoaXMgb25lIHN0aWxsIG5l ZWRzIGEgbGl0dGxlIGJpdCBvZiB3b3JrIGFuZCBpcyBlc3NlbnRpYWxseSB0aGUgc2FtZSANCj4g YXMgdGhlIHZlcnNpb24gcHVibGlzaGVkIGxhc3QgZmVicnVhcnkuIGhvd2V2ZXIsIHdlIHNlZW1l ZCB0byBiZSANCj4gaHVydGxpbmcgdG93YXJkcyBjb25zZW5zdXMgb24gdGhpcyBvbmUuDQo+IA0K PiBWV1JBUCA6IFRydXN0IE1vZGVsIGFuZCBVc2VyIEF1dGhlbnRpY2F0aW9uIA0KPiBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXZ3cmFwLWF1dGhlbnRpY2F0aW9u Lw0KPiANCj4gaSBhZGRlZCByZWZlcmVuY2VzIHRvIHRoZSBDQUxNIGRyYWZ0LCBhbmQgcmVtb3Zl ZCB0aGUgbGVnYWN5IGJpdCBhYm91dCANCj4gYWdlbnQgaWQncy4gaXQncyBub3cgYWxsIGFjY291 bnQgaWRzLCB3aGljaCBpcyB3aGF0IGkgdGhpbmsgd2UgYWxsIA0KPiBzYWlkIHdlIHdhbnRlZC4g TUQ1IGlzIHN0aWxsIGluIHRoZSBkcmFmdCAnY2F1c2UgaSB3YXNuJ3QgY29tcGxldGVseSANCj4g c3VyZSB3ZSBhbGwgYWdyZWVkIHRvIHJlbW92ZSBpdC4gaSBuZWVkIHRvIGFkZCBzb21lIG1vcmUg dmVyYmlhZ2UgDQo+IGFib3V0IHRoZSAidHJ1c3QgbW9kZWwsIiBhbmQgcG9zc2libHkgcmVtb3Zl IHRoZSBNRDUgcmVmZXJlbmNlcyBpZiANCj4gdGhhdCdzIHdoYXQgdGhlIHdvcmtpbmcgZ3JvdXAg d2FudHMgdG8gZG8uDQo+IA0KPiBWV1JBUCA6IENsaWVudCBBcHBsaWNhdGlvbiBMYXVuY2ggTWVz c2FnZSANCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi12d3Jh cC1sYXVuY2gvDQo+IA0KPiB0aGlzIGlzIHRoZSBkcmFmdCB0aGF0IGRlc2NyaWJlcyBob3cgd2Ug c2VuZCBhIG1lc3NhZ2UgZnJvbSBhIHdlYiBzaXRlIA0KPiB0byB0aGUgdmlld2VyIHRvIGxhdW5j aCB0aGUgdmlld2VyLiBpdCdzIGludGVuZGVkIHRvIHN1cHBvcnQgd2ViLWJhc2VkIA0KPiBhdXRo IHNjaGVtZXMgbGlrZSBPcGVuSUQgYW5kIE9BdXRoLiBpIGFkZGVkIGEgbGl0dGxlIG1vcmUgdmVy YmlhZ2UgDQo+IHJlZ2FyZGluZyB0aGUgdXNlIG9mIGEgd2ViIGNhcGFiaWxpdHkgYXMgdGhlIGxv Y2F0aW9uIGZvciBhbiANCj4gYWdlbnRfbG9naW4gcmVzb3VyY2UgYW5kIHRyaWVkIHRvIG1ha2Ug c3VyZSB0aGUgcmVmZXJlbmNlcyB3ZXJlIA0KPiBwb2ludGluZyB0byB0aGUgcmlnaHQgcGxhY2Uu DQo+IA0KPiBzby4uLiBpIGVuY291cmFnZSBldmVyeW9uZSB0byB0YWtlIGEgbG9vayBhdCB0aGVz ZSBkb2NzIGFuZCBsZXQgbWUgDQo+IGtub3cgaWYgeW91IHNlZSBhbnl0aGluZyB3cm9uZyB3aXRo IHRoZW0uDQo+IA0KPiBjaGVlcnMhDQo+IG1lYWRoYmgNCj4gLS0NCj4gbWVhZGhiaCBoYW1yaWNr ICogaXQncyBwcm9ub3VuY2VkICJtYWV2ZSINCj4gQE9oTWVhZGhiaCAqIGh0dHA6Ly9tZWFkaGJo Lm9yZy8gKiBPaE1lYWRoYmhAZ21haWwuY29tIA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiB2d3JhcCBtYWlsaW5nIGxpc3QNCj4gdndyYXBAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92d3JhcA0KDQo= From ohmeadhbh@gmail.com Tue Jul 6 11:34:15 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FA723A6834 for ; Tue, 6 Jul 2010 11:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUXZqAZx7L3w for ; Tue, 6 Jul 2010 11:34:13 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id F208D3A6452 for ; Tue, 6 Jul 2010 11:34:12 -0700 (PDT) Received: by gwb10 with SMTP id 10so3538009gwb.31 for ; Tue, 06 Jul 2010 11:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=kqp+e8oOJjFFBlxaopTw3yYygjAPeEyLX1km/u/xGq8=; b=UOg/xtNdq4zP32UCtIAacpjpMEGpuoOLGPiMEnM/UwdgO08TS9aeiDR8c946dfD5S7 Vh5IKCR1+KzVuzVgLaBgMzS84beKPyaAEQMbP0pvhJ0EA+AwcFHWR1yxc4LhI07TrT7W mEDhM70RcvUR1x3pMNbzbmAjJK+42KVptbUzA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=M55uk/TyaBwTMa+JLdAZqOw8RrZUzpF0Cl6zfcQWbCrpu0PKk2n32qzCtZdhHcjzxk 7H9CD0ZSTOq2416FxEoNLgLGSolJvlr0dxs3GeQsqZeOQe9wTwRsaDs44v7buyy2G5CD d+nRsVvDR/dlZQspKU4MNx1IbbCg3wHwBB3W0= Received: by 10.229.215.12 with SMTP id hc12mr2967310qcb.19.1278441251119; Tue, 06 Jul 2010 11:34:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.185.73 with HTTP; Tue, 6 Jul 2010 11:33:51 -0700 (PDT) In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933DDA75DE93@rrsmsx506.amr.corp.intel.com> References: <4C3354A0.2070304@stpeter.im> <62BFE5680C037E4DA0B0A08946C0933DDA75DE93@rrsmsx506.amr.corp.intel.com> From: Meadhbh Hamrick Date: Tue, 6 Jul 2010 11:33:51 -0700 Message-ID: To: "Hurliman, John" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "vwrap@ietf.org" Subject: Re: [vwrap] New Revisions of VWRAP Internet Drafts Published X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 18:34:15 -0000 yay! comments! a couple comments: 1. didn't we say we wanted to drop the legacy "agent login" and only go with "account login" ? there was a back and forth where i was all about "oh noes! SL will break if we don't do agent login?" and then someone (morgaine?) said "it's okay, SL will cope!" and then josh said, "yeah, SL will cope without agent login in VWRAP, we can login with a single account string." so the most recent auth spec DOESN'T have a first + last agent login option. it only has an account_name string in the auth request. it doesn't sound like this change will cause heartburn for you, john. your thoughts? 2. we had previously said (roughly) "if the &authenticator map is not present in the agent_login message, the auth service will figure out what to do on it's own." so the current draft calls out two options for why the auth service may not see an &authenticator: 1. it's been pre-authenticated or 2. auth info is present in the transport session (either by a TLS client cert or HTTP digest auth.) but... i think i like your way better, john. so, i propose the following new types for authenticators: { "type": "capability" } - as described below { "type": "transport" } - the service should check the transport for either a HTTP digest auth header or a TLS client side cert. -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Tue, Jul 6, 2010 at 10:29 AM, Hurliman, John w= rote: > Now that the CALM draft is alive and kicking again let's see how I can br= eak it :-). One issue I ran into while implementing my launcher app was the= need to distinguish between capability login URLs and unauthenticated logi= n URLs. Here are our use cases: > > a) A user visits sciencesim.com, creates an account and/or logs in, goes = to their start page (let's say sciencesim.com/account/) and clicks a Launch= button that points to a CALM document with a login capability. The launche= r app knows to start the viewer in "pre-authenticated" mode where it skips = the username/password entry form and tries to log directly in-world. > > b) A user wants to login to sciencesim.com using the username/password en= try form built into the viewer, without doing a web authentication first. T= hey have sciencesim.com/launch/ bookmarked which returns a CALM document co= ntaining the unauthenticated login url for sciencesim. This instructs the l= auncher to open the viewer in "username/password prompt mode". > > To achieve both of these use cases I added a new &authenticator that cont= ains { "type": "capability" } to distinguish a pre-authenticated URL from t= he regular variety. I also added a bit of code to look for either "name" or= merge "first_name" + "last_name" into a Name field. The full CALM parsing = code for the launcher is in SVN at . You'll notice a couple of = non-standard extensions ("welcomeurl", "economyurl", "abouturl", "registeru= rl", "helpurl", "passwordurl") that are not part of the spec, but used in t= he launcher app since we're using CALM documents as the hopeful successor t= o GridInfo documents (http://opensimulator.org/wiki/GridInfo). > > John > > > On 7/5/10 4:28 PM, Meadhbh Hamrick wrote: >> from http://blog.meadhbh.org/2010/07/new-vwrap-internet-drafts-published= .html : >> >> hey peeps! this is just a quick note to let you know that i just >> pushed out several new versions of the following VWRAP Internet >> Drafts: >> >> VWRAP : Introduction and Goals >> https://datatracker.ietf.org/doc/draft-ietf-vwrap-intro/ >> >> this is the draft that's intended to be a "gentle introduction" to our >> kind of virtual world, the protocol and the documents. i believe it is >> "very close" to being fully baked. based on feedback from the mailing >> list and face to face meetings, i added a section on deployment >> patterns (without using the terms "Second Life" or "OpenSim",) removed >> the archaic concepts of agent and region domains, added a document >> roadmap and added a few terms in the glossary. also, i fixed up the >> references in the back so they *should* be pointing to the most recent >> revisions of things. >> >> VWRAP : Abstract Type System for the Transmission of Dynamic >> Structured Data >> https://datatracker.ietf.org/doc/draft-ietf-vwrap-type-system/ >> >> this one still needs a little bit of work and is essentially the same >> as the version published last february. however, we seemed to be >> hurtling towards consensus on this one. >> >> VWRAP : Trust Model and User Authentication >> https://datatracker.ietf.org/doc/draft-ietf-vwrap-authentication/ >> >> i added references to the CALM draft, and removed the legacy bit about >> agent id's. it's now all account ids, which is what i think we all >> said we wanted. MD5 is still in the draft 'cause i wasn't completely >> sure we all agreed to remove it. i need to add some more verbiage >> about the "trust model," and possibly remove the MD5 references if >> that's what the working group wants to do. >> >> VWRAP : Client Application Launch Message >> https://datatracker.ietf.org/doc/draft-ietf-vwrap-launch/ >> >> this is the draft that describes how we send a message from a web site >> to the viewer to launch the viewer. it's intended to support web-based >> auth schemes like OpenID and OAuth. i added a little more verbiage >> regarding the use of a web capability as the location for an >> agent_login resource and tried to make sure the references were >> pointing to the right place. >> >> so... i encourage everyone to take a look at these docs and let me >> know if you see anything wrong with them. >> >> cheers! >> meadhbh >> -- >> meadhbh hamrick * it's pronounced "maeve" >> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > From john.hurliman@intel.com Tue Jul 6 11:41:45 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61DB73A6908 for ; Tue, 6 Jul 2010 11:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.37 X-Spam-Level: X-Spam-Status: No, score=-4.37 tagged_above=-999 required=5 tests=[AWL=-2.229, BAYES_00=-2.599, FRT_PROFIT1=3.858, J_CHICKENPOX_54=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 vq6rxbQtMT4A for ; Tue, 6 Jul 2010 11:41:44 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by core3.amsl.com (Postfix) with ESMTP id EC2AC3A6860 for ; Tue, 6 Jul 2010 11:41:43 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 06 Jul 2010 11:41:08 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.53,548,1272870000"; d="scan'208";a="533012663" Received: from rrsmsx604.amr.corp.intel.com ([10.31.0.170]) by orsmga002.jf.intel.com with ESMTP; 06 Jul 2010 11:42:24 -0700 Received: from rrsmsx606.amr.corp.intel.com (10.31.1.130) by rrsmsx604.amr.corp.intel.com (10.31.0.170) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 6 Jul 2010 12:41:42 -0600 Received: from rrsmsx506.amr.corp.intel.com ([10.31.0.39]) by RRSMSX606.amr.corp.intel.com ([10.31.1.130]) with mapi; Tue, 6 Jul 2010 12:41:42 -0600 From: "Hurliman, John" To: "vwrap@ietf.org" Date: Tue, 6 Jul 2010 12:41:41 -0600 Thread-Topic: [vwrap] New Revisions of VWRAP Internet Drafts Published Thread-Index: AcsdOeCmzORRzT/BTbSvK6DM2h1rxgAAJlYA Message-ID: <62BFE5680C037E4DA0B0A08946C0933DDA75DF65@rrsmsx506.amr.corp.intel.com> References: <4C3354A0.2070304@stpeter.im> <62BFE5680C037E4DA0B0A08946C0933DDA75DE93@rrsmsx506.amr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [vwrap] New Revisions of VWRAP Internet Drafts Published X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 18:41:45 -0000 > -----Original Message----- > From: Meadhbh Hamrick [mailto:ohmeadhbh@gmail.com] > Sent: Tuesday, July 06, 2010 11:34 AM > To: Hurliman, John > Cc: vwrap@ietf.org > Subject: Re: [vwrap] New Revisions of VWRAP Internet Drafts Published >=20 > yay! comments! >=20 > a couple comments: >=20 > 1. didn't we say we wanted to drop the legacy "agent login" and only go w= ith > "account login" ? there was a back and forth where i was all about "oh no= es! > SL will break if we don't do agent login?" and then someone (morgaine?) s= aid > "it's okay, SL will cope!" and then josh said, "yeah, SL will cope withou= t agent > login in VWRAP, we can login with a single account string." >=20 > so the most recent auth spec DOESN'T have a first + last agent login opti= on. it > only has an account_name string in the auth request. >=20 > it doesn't sound like this change will cause heartburn for you, john. > your thoughts? >=20 This works for me. I wrote that parser when the discussion was still happen= ing and tried to bullet-proof it against the first+last possibility, but it= sounds like I need to change name to account_name and it should be safe to= drop the first_name+last_name support since there are no other CALM implem= entations at the moment. I'll make this change in the next release. > 2. we had previously said (roughly) "if the &authenticator map is not pre= sent > in the agent_login message, the auth service will figure out what to do o= n it's > own." so the current draft calls out two options for why the auth service= may > not see an &authenticator: 1. it's been pre-authenticated or 2. auth info= is > present in the transport session (either by a TLS client cert or HTTP dig= est > auth.) >=20 > but... i think i like your way better, john. so, i propose the following = new > types for authenticators: >=20 > { "type": "capability" } - as described below { "type": "transport" } - t= he > service should check the transport for either a HTTP digest auth header o= r a > TLS client side cert. >=20 This looks good to me. > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >=20 >=20 >=20 > On Tue, Jul 6, 2010 at 10:29 AM, Hurliman, John > wrote: > > Now that the CALM draft is alive and kicking again let's see how I can = break > it :-). One issue I ran into while implementing my launcher app was the n= eed > to distinguish between capability login URLs and unauthenticated login UR= Ls. > Here are our use cases: > > > > a) A user visits sciencesim.com, creates an account and/or logs in, goe= s to > their start page (let's say sciencesim.com/account/) and clicks a Launch > button that points to a CALM document with a login capability. The launch= er > app knows to start the viewer in "pre-authenticated" mode where it skips > the username/password entry form and tries to log directly in-world. > > > > b) A user wants to login to sciencesim.com using the username/password > entry form built into the viewer, without doing a web authentication firs= t. > They have sciencesim.com/launch/ bookmarked which returns a CALM > document containing the unauthenticated login url for sciencesim. This > instructs the launcher to open the viewer in "username/password prompt > mode". > > > > To achieve both of these use cases I added a new &authenticator that > contains { "type": "capability" } to distinguish a pre-authenticated URL = from > the regular variety. I also added a bit of code to look for either "name"= or > merge "first_name" + "last_name" into a Name field. The full CALM parsing > code for the launcher is in SVN at > r/LaunchDocument.cs>. You'll notice a couple of non-standard extensions > ("welcomeurl", "economyurl", "abouturl", "registerurl", "helpurl", > "passwordurl") that are not part of the spec, but used in the launcher ap= p > since we're using CALM documents as the hopeful successor to GridInfo > documents (http://opensimulator.org/wiki/GridInfo). > > > > John > > > > > > On 7/5/10 4:28 PM, Meadhbh Hamrick wrote: > >> from http://blog.meadhbh.org/2010/07/new-vwrap-internet-drafts- > published.html : > >> > >> hey peeps! this is just a quick note to let you know that i just > >> pushed out several new versions of the following VWRAP Internet > >> Drafts: > >> > >> VWRAP : Introduction and Goals > >> https://datatracker.ietf.org/doc/draft-ietf-vwrap-intro/ > >> > >> this is the draft that's intended to be a "gentle introduction" to > >> our kind of virtual world, the protocol and the documents. i believe > >> it is "very close" to being fully baked. based on feedback from the > >> mailing list and face to face meetings, i added a section on > >> deployment patterns (without using the terms "Second Life" or > >> "OpenSim",) removed the archaic concepts of agent and region domains, > >> added a document roadmap and added a few terms in the glossary. also, > >> i fixed up the references in the back so they *should* be pointing to > >> the most recent revisions of things. > >> > >> VWRAP : Abstract Type System for the Transmission of Dynamic > >> Structured Data > >> https://datatracker.ietf.org/doc/draft-ietf-vwrap-type-system/ > >> > >> this one still needs a little bit of work and is essentially the same > >> as the version published last february. however, we seemed to be > >> hurtling towards consensus on this one. > >> > >> VWRAP : Trust Model and User Authentication > >> https://datatracker.ietf.org/doc/draft-ietf-vwrap-authentication/ > >> > >> i added references to the CALM draft, and removed the legacy bit > >> about agent id's. it's now all account ids, which is what i think we > >> all said we wanted. MD5 is still in the draft 'cause i wasn't > >> completely sure we all agreed to remove it. i need to add some more > >> verbiage about the "trust model," and possibly remove the MD5 > >> references if that's what the working group wants to do. > >> > >> VWRAP : Client Application Launch Message > >> https://datatracker.ietf.org/doc/draft-ietf-vwrap-launch/ > >> > >> this is the draft that describes how we send a message from a web > >> site to the viewer to launch the viewer. it's intended to support > >> web-based auth schemes like OpenID and OAuth. i added a little more > >> verbiage regarding the use of a web capability as the location for an > >> agent_login resource and tried to make sure the references were > >> pointing to the right place. > >> > >> so... i encourage everyone to take a look at these docs and let me > >> know if you see anything wrong with them. > >> > >> cheers! > >> meadhbh > >> -- > >> meadhbh hamrick * it's pronounced "maeve" > >> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > >> _______________________________________________ > >> vwrap mailing list > >> vwrap@ietf.org > >> https://www.ietf.org/mailman/listinfo/vwrap > > > > _______________________________________________ > > vwrap mailing list > > vwrap@ietf.org > > https://www.ietf.org/mailman/listinfo/vwrap > > From ohmeadhbh@gmail.com Tue Jul 6 12:19:49 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0032E3A6830 for ; Tue, 6 Jul 2010 12:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQSjKRw--r8B for ; Tue, 6 Jul 2010 12:19:47 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id C44C33A692C for ; Tue, 6 Jul 2010 12:19:46 -0700 (PDT) Received: by qwe5 with SMTP id 5so2357358qwe.31 for ; Tue, 06 Jul 2010 12:19:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type:content-transfer-encoding; bh=LRvU/FZ8E/ngQ0ziAX4FBhv0Iqgoaz1W+PLMBKBY9YM=; b=GIjESfVIKIbcFBaRgey+kUdyd+ymBf8QXkftwatKltKSDIiGng6d6PIkxBv61Uxf2n L2UgzM/Z092jf2oApnWET7PKpeppZwUo0Cakf6/xFXUJpwGvI4J/QK17rhVjSvOKFA5D BtlZw/xGEXBodFGza6l25XIuuPanwEIcpnlzc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; b=Kbk9Lp03CQMwuTt2CCET2SDVnCbyBmyPyFdOssOsw/M8+ElXjk5Gvenz0bYD54Wy9Q wAsyHdufLXqiN+GhwQ5jxpj1y1G/46jc0iafMEdnUFMPcB+78X8CH4mcDHf5ZVHE4CUl 1M/MMWD8SJggLu54JKoKEVbChUmhwl1Tg2c7s= Received: by 10.224.66.88 with SMTP id m24mr2785932qai.217.1278443986265; Tue, 06 Jul 2010 12:19:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.185.73 with HTTP; Tue, 6 Jul 2010 12:19:26 -0700 (PDT) From: Meadhbh Hamrick Date: Tue, 6 Jul 2010 12:19:26 -0700 Message-ID: To: vwrap@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [vwrap] MD5 must die [was: Re: authentication : remove reference to MD5] X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 19:19:49 -0000 so i was thinking about auth things and thought i would revive this thread.= .. MD5 is bad, i think we all agree. US-CERT's advisory "MD5 vulnerable to collision attacks" @ http://www.kb.cert.org/vuls/id/836068 explains why. we had a couple of good recommendations: 1. patnad and barry said, "just force people to re-register and store the new password hash." and that's probably a good idea. 2. sean mentioned, "just keep legacy SL running the old system while everyone else uses the new." and that's probably a good idea too. 3. we could also do something funky like say that for peeps like SL, hash the password first with MD5, and then with SHA256. (i.e. - you use the MD5 hash as the shared secret instead of the password.) linden unfortunately has a bazillion users whose passwords are "stored" as MD5 hashes. and i wanted to ask josh and/or joe (who as far as i know) still work at linden... what do you think about this? is there a preference from linden? you guys are going to be the most affected. so to paraphrase winston churchill: "we know it will be hard; we expect it to be long, we cannot predict or measure its episodes or its tribulations. but one thing is certain, one thing is sure, one thing stands out stark and undeniable, massive and unassailable for all the world to see. we cannot see how deliverance will come or when it will come, but nothing is more certain that every trace of MD5's footsteps, every stain of its infected, corroding fingers will be expunged and purged and, if need be, blasted from the surface of the (virtual) earth." -cheers, etc. -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Wed, Apr 7, 2010 at 9:58 AM, Sean Hennessee wrote: > If VWRAP has no legacy support, can't the implementors still have mixed m= ode > support as long as they decide to? Just because an implementor supports > VWRAP, (with no legacy support), doesn't necessarily mean they can't supp= ort > legacy protocols as well. Eventually one would hope all would transition = to > only VWRAP, but implementors are really the determining factor of how lon= g > that transition takes. Even many web browsers continue to support old > versions of the HTML spec while still supporting newer versions. > > Perhaps VWRAP should include a protocol negotiation protocol allowing > services to determine what protocols and versions of protocols are suppor= ted > on each end. "Sorry, your client is not supported on this sim" should be = an > option. I see (saw) it often when connecting to SL after major client/ser= ver > updates. > > Peace, > Sean > > Meadhbh Hamrick wrote: >> >> actually. that does bring up a good point. LL _could_ just invalidate >> everyone's password and make them go through password reset. >> >> i agree, patnad, i would do it too, but it may be difficult to >> convince everyone to do it, and i'm not sure it's the kind of thing a >> standards organization should require of one of it's implementers. >> >> just my $0.02, but yeah, i'll let the lindens speak for themselves. >> -- >> meadhbh hamrick * it's pronounced "maeve" >> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> >> >> >> On Tue, Apr 6, 2010 at 4:18 PM, Patnad Babii wrote: >>> >>> I think if someday LL ask me to change my password because they made >>> their >>> security system better i would really not mind. So typing a password ta= ke >>> 1 >>> minute for changing it. >>> >>> Same for all opensim grid if they someday ask me to change my password >>> because they enforced security i'd be more than happy to provide them >>> with a >>> new one. >>> >>> I don't think people will leave SL just because you "forced" them to >>> change >>> a password honestly. >>> >>> -------------------------------------------------- >>> From: "Meadhbh Hamrick" >>> Sent: Tuesday, April 06, 2010 2:22 PM >>> To: "Peter Saint-Andre" >>> Cc: >>> Subject: Re: [vwrap] authentication : remove reference to MD5 >>> >>>> we need clarification about how much of the second life legacy >>>> protocol will be used in VWRAP. >>>> >>>> for instance. second life stores the MD5 hash of user passwords in the >>>> user database and uses it to authenticate users when logging in. >>>> >>>> but MD5 has some significant problems which were exacerbated several >>>> years ago when there was a security breach of linden's servers. >>>> >>>> so if we simply said "we're going to ditch MD5 in favor of SHA256" >>>> there would be a problem with reverse compatibility of the >>>> authentication data. this is because you can't generate the pre-image >>>> from an MD5 MIC and then use it to generate a SHA256 MIC. (or you >>>> can't do that in a way that insures that your MD5 pre image is the >>>> same as the password.) >>>> >>>> so in other words, there is an action we could take in this group that >>>> COULD make it very difficult for linden and presumably existing >>>> OpenSim instances to use the authentication protocol. >>>> >>>> so the question is, to which degree do we add an engineering burden to >>>> existing implementations that would like to adopt this group's output? >>>> the question of the two string identifier is a good one. linden could >>>> probably make systems that adhere to all sorts of different changes. >>>> but to what degree to we make it easy for existing implementers vs. >>>> the desires of people who have yet to build and implementation? >>>> >>>> -cheers >>>> -meadhbh >>>> >>>> >>>> -- >>>> meadhbh hamrick * it's pronounced "maeve" >>>> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >>>> >>>> >>>> >>>> On Tue, Apr 6, 2010 at 11:01 AM, Peter Saint-Andre >>>> wrote: >>>>> >>>>> On 4/6/10 8:19 AM, Meadhbh Hamrick wrote: >>>>>> >>>>>> okay. >>>>>> >>>>>> if we're going to remove VWRAP from all current implementations, >>>>> >>>>> What does that mean? I thought we were trying to build VWRAP into >>>>> implementations, not rip it out. :) >>>>> >>>>>> i >>>>>> vote we remove MD5 from the auth spec and replace it with a MIC with >>>>>> better security properties, like SHA224 or SHA256. >>>>> >>>>> +1 to more secure authentication. >>>>> >>>>> My quick reading of the authentication draft led me to think that it >>>>> needed a thorough review, but unfortunately I haven't had time to do >>>>> that yet. >>>>> >>>>> Peter >>>>> >>>>> -- >>>>> Peter Saint-Andre >>>>> https://stpeter.im/ > > -- > > Sean Hennessee > Central Computing Support > Office of Information Technology > UC Irvine > > > ... . .- -. / =A0.... . -. -. . ... ... . . > From stpeter@stpeter.im Tue Jul 6 12:38:33 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2E4E3A6A36 for ; Tue, 6 Jul 2010 12:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 tSaOpoVtorRc for ; Tue, 6 Jul 2010 12:38:33 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id DCE673A6A3A for ; Tue, 6 Jul 2010 12:38:30 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 93FD440E38 for ; Tue, 6 Jul 2010 13:38:32 -0600 (MDT) Message-ID: <4C338636.9060106@stpeter.im> Date: Tue, 06 Jul 2010 13:38:30 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: vwrap@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060909000002050201090608" Subject: Re: [vwrap] MD5 must die [was: Re: authentication : remove reference to MD5] X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 19:38:33 -0000 This is a cryptographically signed message in MIME format. --------------ms060909000002050201090608 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 7/6/10 1:19 PM, Meadhbh Hamrick wrote: > so to paraphrase winston churchill: "we know it will be hard; we > expect it to be long, we cannot predict or measure its episodes or its > tribulations. but one thing is certain, one thing is sure, one thing > stands out stark and undeniable, massive and unassailable for all the > world to see. we cannot see how deliverance will come or when it will > come, but nothing is more certain that every trace of MD5's footsteps, > every stain of its infected, corroding fingers will be expunged and > purged and, if need be, blasted from the surface of the (virtual) > earth." MD5 Delenda Est! But remember, Carthage wasn't destroyed in a day. ;-) /psa --------------ms060909000002050201090608 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDcwNjE5MzgzMFowIwYJKoZIhvcNAQkEMRYEFDTbUQxojQn4RuwvoqTP SAkImmlXMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAl6Zt9fRu7Q8m0PTZu2Ut+YZnF3WpBC4Heu7Pms2D bxePlW5zr5gP7zjBsv3/7NtJn6CCT+y1jIrlDLgJpLyLbPZCObQMsHJjzYWf2MDG64HHQl7m sThhDifGrR2Ct+BhR4PgaeTxL7kU/LxxUHwNRnm+6cE0XsPzFoTgF94ySnWqyzUvSSrp1bvm gTb7x1LZJ52YKic2RnkD3RWdk7NMdzdDnygvDclEdoPKIVmaNd9dfVaOYTwfvbGOeF9pofM3 gNGhWvXbrnD12bR9mrqHMD8H6r4DD8PxuFY6mkJToQ8DqtT4i3SvRE0sCzMyUbg9QI7Nttd6 eWZi0D2CwWLbPwAAAAAAAA== --------------ms060909000002050201090608-- From tme@americafree.tv Tue Jul 6 13:25:05 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F14C83A692C for ; Tue, 6 Jul 2010 13:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.669 X-Spam-Level: X-Spam-Status: No, score=-101.669 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nG-64vcEzJdM for ; Tue, 6 Jul 2010 13:25:04 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id F10B83A68E7 for ; Tue, 6 Jul 2010 13:25:03 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id EC4217D4B157; Tue, 6 Jul 2010 16:25:05 -0400 (EDT) Message-Id: <482C3C95-0020-4313-9493-24C2F505F8DD@americafree.tv> From: Marshall Eubanks To: Peter Saint-Andre In-Reply-To: <4C338636.9060106@stpeter.im> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 6 Jul 2010 16:25:04 -0400 References: <4C338636.9060106@stpeter.im> X-Mailer: Apple Mail (2.936) Cc: vwrap@ietf.org Subject: Re: [vwrap] MD5 must die [was: Re: authentication : remove reference to MD5] X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 20:25:05 -0000 On Jul 6, 2010, at 3:38 PM, Peter Saint-Andre wrote: > On 7/6/10 1:19 PM, Meadhbh Hamrick wrote: > >> so to paraphrase winston churchill: "we know it will be hard; we >> expect it to be long, we cannot predict or measure its episodes or >> its >> tribulations. but one thing is certain, one thing is sure, one thing >> stands out stark and undeniable, massive and unassailable for all the >> world to see. we cannot see how deliverance will come or when it will >> come, but nothing is more certain that every trace of MD5's >> footsteps, >> every stain of its infected, corroding fingers will be expunged and >> purged and, if need be, blasted from the surface of the (virtual) >> earth." > > MD5 Delenda Est! But remember, Carthage wasn't destroyed in a day. ;-) > Yes, and SHA-1 is getting past its due date as well. Marshall > /psa > > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap From josh@lindenlab.com Tue Jul 6 13:50:22 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B96F3A693B for ; Tue, 6 Jul 2010 13:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.117 X-Spam-Level: X-Spam-Status: No, score=-0.117 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMpzclMwcPmw for ; Tue, 6 Jul 2010 13:50:21 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 90ABB3A6807 for ; Tue, 6 Jul 2010 13:50:19 -0700 (PDT) Received: by vws14 with SMTP id 14so6522462vws.31 for ; Tue, 06 Jul 2010 13:50:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.61.9 with SMTP id r9mr2407733vch.263.1278449419166; Tue, 06 Jul 2010 13:50:19 -0700 (PDT) Received: by 10.220.181.132 with HTTP; Tue, 6 Jul 2010 13:50:19 -0700 (PDT) In-Reply-To: References: Date: Tue, 6 Jul 2010 13:50:19 -0700 Message-ID: From: Joshua Bell To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=e0cb4e8873dd7e23dd048abe33ab Subject: Re: [vwrap] MD5 must die [was: Re: authentication : remove reference to MD5] X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 20:50:22 -0000 --e0cb4e8873dd7e23dd048abe33ab Content-Type: text/plain; charset=UTF-8 On Tue, Jul 6, 2010 at 12:19 PM, Meadhbh Hamrick wrote: > MD5 is bad, i think we all agree. US-CERT's advisory "MD5 vulnerable > to collision attacks" @ http://www.kb.cert.org/vuls/id/836068 explains > why. > > we had a couple of good recommendations: > > 1. patnad and barry said, "just force people to re-register and store > the new password hash." and that's probably a good idea. > > 2. sean mentioned, "just keep legacy SL running the old system while > everyone else uses the new." and that's probably a good idea too. > > 3. we could also do something funky like say that for peeps like SL, > hash the password first with MD5, and then with SHA256. (i.e. - you > use the MD5 hash as the shared secret instead of the password.) > > linden unfortunately has a bazillion users whose passwords are > "stored" as MD5 hashes. and i wanted to ask josh and/or joe (who as > far as i know) still work at linden... what do you think about this? > is there a preference from linden? you guys are going to be the most > affected. (speaking as participant) Yep, still here. No preference from Linden; I think you should disregard Linden needs on this particular issue. * (1) is, of course, a possible option; * (2) could be satisfied by Linden releasing a technical note (etc) on an extension to VWRAP Auth that "introduces" algorithm=md5 (i.e. puts back the text that is proposed to be cut); this would be sufficient for clients that wished to auth against both "vanilla" VWRAP and potentially special-case SL * (3) ditto, as a way of doing #2 with increased security during transport ("md5+sha256") - nice thought, Meadhbh! * And, of course, there's the option of doing out-of-band authentication using OpenID (etc) via CALM or the equivalent. None of these appear to require codifying in the spec now, as long as there are no "MUST NOT" requirements that forbid extensions (which would be bad anyway), and Linden doesn't have sufficient data to commit to a particular approach at this time. Joshua --e0cb4e8873dd7e23dd048abe33ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 6, 2010 at 12:19 PM, Meadhbh Hamrick= <ohmeadhbh@gma= il.com> wrote:
MD5 is bad, i think we all agree. US-CERT's advisory "MD5 vulnerab= le
to collision attacks" @ http://www.kb.cert.org/vuls/id/836068 explains why.

we had a couple of good recommendations:

1. patnad and barry said, "just force people to re-register and store<= br> the new password hash." and that's probably a good idea.

2. sean mentioned, "just keep legacy SL running the old system while everyone else uses the new." and that's probably a good idea too.<= br>
3. we could also do something funky like say that for peeps like SL,
hash the password first with MD5, and then with SHA256. (i.e. - you
use the MD5 hash as the shared secret instead of the password.)

linden unfortunately has a bazillion users whose passwords are
"stored" as MD5 hashes. and i wanted to ask josh and/or joe (who = as
far as i know) still work at linden... what do you think about this?
is there a preference from linden? you guys are going to be the most
affected.

(speaking as participant)

Yep, still here.

No preference f= rom Linden; I think you should disregard Linden needs on this particular is= sue.=C2=A0

* (1) is, of course, a possible option;=C2=A0
* (2) could be satisfied by Linden releasing a technical note (etc) on an = extension to VWRAP Auth that "introduces" algorithm=3Dmd5 (i.e. p= uts back the text that is proposed to be cut); this would be sufficient for= clients that wished to auth against both "vanilla" VWRAP and pot= entially special-case SL
* (3) ditto, as a way of doing #2 with increased security during trans= port ("md5+sha256") - nice thought, Meadhbh!
* And, of = course, there's the option of doing out-of-band authentication using Op= enID (etc) via CALM or the equivalent.

None of these appear to require codifying in the spec n= ow, as long as there are no "MUST NOT" requirements that forbid e= xtensions (which would be bad anyway), and Linden doesn't have sufficie= nt data to commit to a particular approach at this time.

Joshua

--e0cb4e8873dd7e23dd048abe33ab-- From ohmeadhbh@gmail.com Wed Jul 7 11:30:27 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 168AD3A68E0 for ; Wed, 7 Jul 2010 11:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.857 X-Spam-Level: X-Spam-Status: No, score=-0.857 tagged_above=-999 required=5 tests=[AWL=-1.743, BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, 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 FRz5uZLiVifQ for ; Wed, 7 Jul 2010 11:30:24 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id D95123A67E5 for ; Wed, 7 Jul 2010 11:30:21 -0700 (PDT) Received: by gwb10 with SMTP id 10so4169791gwb.31 for ; Wed, 07 Jul 2010 11:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=XBKySKTfKIP0p+2HJz2O+zbmjlPZiLKUMJjYefapHAs=; b=hpySogM0FvI4T2wxiz/++xyM3OHPtABKXM3MYbTKhGtjERiayULYBlWpTEyxlMIFxM MWGPVNFPqFoWbmj9tyJJLB/xI3Z6Rh+lzNoC6y0+XRoh+AT010f8t4kfKvJZx610rg3d YW6wxj1WqtN+DLNmiujUzXb8BxlenLgQplitw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=P6LKdTOeANyxy6Qs5+Iivngh3Rd6PexUPalL04p1j2Wf+cSo3lxN+K84ANEuE0SLRx NjylXz62l4dCbydGUMxMtIqZZaq+Jb1PFKMVGtrhIa1gDSog1hoV3CyVF4gh/zxAlZG5 FAfOizaWcqFUrWIP9EZFvRNWPHwHHAZAftSRA= Received: by 10.229.226.81 with SMTP id iv17mr4037174qcb.290.1278527406197; Wed, 07 Jul 2010 11:30:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.185.73 with HTTP; Wed, 7 Jul 2010 11:29:46 -0700 (PDT) From: Meadhbh Hamrick Date: Wed, 7 Jul 2010 11:29:46 -0700 Message-ID: To: "Hurliman, John" , vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016e65bba62e1e6f3048ad05b0e Subject: [vwrap] adding transport and capability auth types, removing MD5 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 18:30:27 -0000 --0016e65bba62e1e6f3048ad05b0e Content-Type: text/plain; charset=ISO-8859-1 so i made some quick mods to the auth draft to remove MD5 and add the transport and capability authenticator types. sections 2.3, 2.10 and 4 have changed, here's the new sections. changes are highlighted. does this look about right to everyone else? the new section 2.3 2.3. Inputs 2.3.1. Account Identifier The account_name key in the credential provided to the authentication service is used to identify the account. This is the opaque sequence of octets used by the authentication service to identify the user. 2.3.2. Hashed Password Authenticator *When a hashed password is used as an authenticator, the string '$1$' is prepended to the UTF-8 encoding of the password and processed with the SHA256 cryptographic hash function [sha256]. This revision of the Virtual World Region Agent Protocol specification requires the use of SHA256 with the hashed password authenticator. It also requires the presence of the algorithm key, and that the value of this key be the string 'sha256'. Note that future versions of this specification may ALLOW or REQUIRE the use of other cryptographic hash functions.* 2.3.3. Challenge-Response Authenticator The Challenge-Response scheme allows the authentication service to select a session specific "Salt" to be used in conjunction with the user's password to generate an authenticator. In this scheme the authenticator is the hash of the salt prepended to the hash of '$1$' prepended to the password. This revision of the Virtual World Region Agent Protocol specification requires the use of SHA256 with the challenge-response authenticator. [sha256] It also requires the presence of the algorithm key, and that the value of this key be the string 'sha256'. Note that future versions of this specification may ALLOW or REQUIRE the use of other cryptographic hash functions. To retrieve a session specific salt for use with the Challenge- Response authentication scheme from the authentication service, the client application sends a login request with a Challenge-Response authenticator without the secret item. If the agent domain supports this authenticator, it MUST respond with a 'key' condition including a salt and MAY include a duration in the response. If the duration is present, it denotes the number of seconds for which the salt will be valid. 2.3.4. PKCS#5 PBKDF2 Authenticator The PKCS#5 PBKDF2 authenticator is an implementation of RSA Labs' Public Key Cryptographic Standards #5 v2.1 Password Based Key Derivation Function #2. [pkcs5] In this scheme, the string '$1$' is prepended to the password is used in conjunction with a salt, iteration count and hash function to generate an authenticator. This revision of the Virtual World Region Agent Protocol specification requires the use of SHA256 with the PKCS#5 PBKDS2 authenticator. It also requires the presence of the algorithm key, and that the value of this key be the string 'sha256'. Note that future versions of this specification may ALLOW or REQUIRE the use of other cryptographic hash functions. As with the Challenge-Response authenticator, the authentication service MUST include the salt and iteration count in its response to an authentication request that is made without a secret item. Conforming authentication services may include a duration in their response indicating the number of seconds for which the salt and iteration count will be valid. *2.3.5. Capability Authenticator The VWRAP Client Application Launch Message document [I-D.ietf-vwrap-launch] describes a technique for using "web based" authentication services such as OAuth [RFC5849] or OpenID [OPENID]. One technique for ensuring the security of the client application launch message is for it to reference an agent_login resource on a web capability. Because the address of the capability is cryptographically unguessable, it is assumed that only the authenticated client will know the resource's address. In this use case, the client does not need to include proof of a shared secret in the agent_login request itself. Knowledge of the agent_login's address carries equivalent proof of the client's authorization. The "capability authenticator" is used in this use case. Authentication services are to interpret it's presence in an agent_login request as signaling the use of a previously established web based authentication service. Authentication services that do not offer web based authentication MUST return an authentication failure response. 2.3.6. Transport Based Authenticator Authentication messages may flow over transports that provide authentication or authorization. HTTP Basic Authentication, Digest Authentication [RFC2617] and TLS Client Certificates [RFC5246]are popular techniques for authenticating one end of a network connection at the transport level.Though the objective of VWRAP authetication is to verify the origin integrity of an "application layer" entity, such credentials sometimes span layers. In some environments, application layer credentials are assumed to be available to the transport. Guidelines for transport-based authentication are provided later in this document. Conformant implementations wishing to use transport layer authentication MUST signal their intent by including a "transport" type authenticator in the agent_login message. Note there are no map elements save the "type" indicator in the transport based authenticator. This is because actual authentication data is provided by the transport.* the new section 2.10 2.10. Interface The following text describes the interface description of the agent_login messages.[I-D.ietf-vwrap-type-system] ; authenticators ; hashed password authenticator &authenticator = { type: 'hash', ; identifies this as "hashed" type algorithm: '*sha256*', ; secret: binary ; hash of salt prepended to the password; ; s = h( '$1$' | pw ) } ; challenge response style authenticator &authenticator = { type: 'challenge', ; identifies this as a "challenge response" algorithm: 'sha256', ; salt: binary, ; optional - default is 0x24, 0x31, 0x24 secret: binary ; hash of the salt prepended to password ; s = h( salt | h( '$1$' | pw ) ) } ; PKCS#5 PBKDF2 style authenticator &authenticator = { type: 'pkcs5pbkdf2', ; identifies authenticator as PKCS#5 PBKDF2 algorithm: string, ; identifier for hash ('sha256') salt: binary, ; optional - default is 0x24, 0x31, 0x24 count: int, ; optional - 1 used if not present secret: binary ; hash of the salt prepended to password ; s = pbkdf2( h('$1$' |pw),salt,count,128) } * ; Capability &authenticator = { type: 'capability' ; identifies "capability" authentication } ; Transport &authenticator = { type: 'transport', ; identifies "transport based" auth }* ; request &credential = { account_name: string, authenticator: &authenticator ; 'hash' 'challenge' or 'pkcs5pbkdf2' } ; response ; successful response &response = { condition: 'success', agent_seed_capability: uri ; URL of the agent seed cap } ; authentication failure &response = { condition: 'key', salt: binary, ; optional - salt for challenge and PKCS5 count: int, ; optional - iteration count for PKCS5 duration: int ; optional - the duration of the validity ; period of salt and count values in ; seconds } ; maintenance "non success" &response = { condition: 'maintenance', maintenance_capability: uri, ; URL of the maintenance cap completion: int ; estimate for maintenance duration ; (in seconds) } ; administrative failure &response = { condition: 'intervention', message: uri ; a URI with human-readable text ; explaining what the user must do to ; continue } ; non-specific error &response = { condition: 'nonspecific', message: string ; a string describing the failure } ; resource definition %% agent_login -> &credential <- &response the new section 4 4. Security Considerations RFC 3552 [RFC3552] describes several aspects to use when evaluating the security of a specification or implementation. We believe most common security concerns users of this specification will encounter are more appropriately considered as transport, network or link layer issues. However, the following "application security" issues should be considered. *A previous version of this document specified the use of the MD5 cryptographic hash function [RFC1321]. Its use has been deprecated and MUST NOT be used with VWRAP agent_login requests.* The use of the hashed password authenticator could result in a replay attack if not used in conjunction with an appropriate confidentiality preserving transport. Implementations using the hashed password authenticator SHOULD utilize appropriate encryption schemes such as TLS [RFC5246] or S/MIME [RFC3851]. -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com --0016e65bba62e1e6f3048ad05b0e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable so i made some quick mods to the auth draft to remove MD5 and add the trans= port and capability authenticator types. sections 2.3, 2.10 and 4 have chan= ged, here's the new sections. changes are highlighted. does this look a= bout right to everyone else?

the new section 2.3

2.3. =A0Inputs

2.3.1. =A0Account Iden= tifier

=A0 The account_name key in the credential provided to the a= uthentication
=A0 service is used to identify the account. =A0This is the opaque sequenc= e
=A0 of octets used by the authentication service to identify the user= .

2.3.2. =A0Hashed Password Authenticator

=A0 When a hash= ed password is used as an authenticator, the string '$1$'
=A0 is prepended to the UTF-8 encoding of the password and processed with<= br> =A0 the SHA256 cryptographic hash function [sha256]. =A0This revision o= f
=A0 the Virtual World Region Agent Protocol specification requires th= e
=A0 use of SHA256 with the hashed password authenticator. =A0It also
= =A0 requires the presence of the algorithm key, and that the value of
= =A0 this key be the string 'sha256'. =A0Note that future versions o= f this
=A0 specification may ALLOW or REQUIRE the use of other cryptographic
= =A0 hash functions.

2.3.3. =A0Challenge-Response Authenticator
=A0 The Challenge-Response scheme allows the authentication service = to
=A0 select a session specific "Salt" to be used in conjunction w= ith the
=A0 user's password to generate an authenticator. =A0In thi= s scheme the
=A0 authenticator is the hash of the salt prepended to the= hash of '$1$'
=A0 prepended to the password. =A0This revision of the Virtual World Regio= n
=A0 Agent Protocol specification requires the use of SHA256 with the<= br> =A0 challenge-response authenticator. [sha256] It also requires the
= =A0 presence of the algorithm key, and that the value of this key be the =A0 string 'sha256'. =A0Note that future versions of this specific= ation may
=A0 ALLOW or REQUIRE the use of other cryptographic hash func= tions.

=A0 To retrieve a session specific salt for use with the Cha= llenge-
=A0 Response authentication scheme from the authentication service, the =A0 client application sends a login request with a Challenge-Response =A0 authenticator without the secret item. =A0If the agent domain support= s
=A0 this authenticator, it MUST respond with a 'key' condition inc= luding
=A0 a salt and MAY include a duration in the response. =A0If the= duration
=A0 is present, it denotes the number of seconds for which th= e salt will
=A0 be valid.

2.3.4. =A0PKCS#5 PBKDF2 Authenticator

=A0 The= PKCS#5 PBKDF2 authenticator is an implementation of RSA Labs'
=A0 = Public Key Cryptographic Standards #5 v2.1 Password Based Key
=A0 Deriv= ation Function #2. [pkcs5] In this scheme, the string '$1$' is
=A0 prepended to the password is used in conjunction with a salt,
=A0 = iteration count and hash function to generate an authenticator. =A0This
= =A0 revision of the Virtual World Region Agent Protocol specification
= =A0 requires the use of SHA256 with the PKCS#5 PBKDS2 authenticator. =A0It<= br> =A0 also requires the presence of the algorithm key, and that the value =A0 of this key be the string 'sha256'. =A0Note that future versi= ons of
=A0 this specification may ALLOW or REQUIRE the use of other
= =A0 cryptographic hash functions.

=A0 As with the Challenge-Response authenticator, the authentication =A0 service MUST include the salt and iteration count in its response to=
=A0 an authentication request that is made without a secret item.
= =A0 Conforming authentication services may include a duration in their
=A0 response indicating the number of seconds for which the salt and
= =A0 iteration count will be valid.

2.3.5. =A0Capability Authentic= ator

=A0 The VWRAP Client Application Launch Message document
= =A0 [I-D.ietf-vwrap-launch] describes a technique for using "web based= "
=A0 authentication services such as OAuth [RFC5849] or OpenID [OPENID]. =A0 One technique for ensuring the security of the client application
= =A0 launch message is for it to reference an agent_login resource on a
= =A0 web capability. =A0Because the address of the capability is
=A0 cryptographically unguessable, it is assumed that only the
=A0 aut= henticated client will know the resource's address.

=A0 In this= use case, the client does not need to include proof of a
=A0 shared se= cret in the agent_login request itself. =A0Knowledge of the
=A0 agent_login's address carries equivalent proof of the client's=
=A0 authorization.

=A0 The "capability authenticator"= ; is used in this use case.
=A0 Authentication services are to interpre= t it's presence in an
=A0 agent_login request as signaling the use of a previously established =A0 web based authentication service. =A0Authentication services that do=
=A0 not offer web based authentication MUST return an authentication =A0 failure response.

2.3.6. =A0Transport Based Authenticator

=A0 Authentication mess= ages may flow over transports that provide
=A0 authentication or author= ization. =A0HTTP Basic Authentication, Digest
=A0 Authentication [RFC26= 17] and TLS Client Certificates [RFC5246]are
=A0 popular techniques for authenticating one end of a network connection<= br> =A0 at the transport level.Though the objective of VWRAP authetication = is
=A0 to verify the origin integrity of an "application layer&quo= t; entity, such
=A0 credentials sometimes span layers. =A0In some environments, applicatio= n
=A0 layer credentials are assumed to be available to the transport.
=A0 Guidelines for transport-based authentication are provided later= in
=A0 this document. =A0Conformant implementations wishing to use transport<= br> =A0 layer authentication MUST signal their intent by including a
= =A0 "transport" type authenticator in the agent_login message.
=A0 Note there are no map elements save the "type" indicator in = the
=A0 transport based authenticator. =A0This is because actual authenticatio= n
=A0 data is provided by the transport.
the new se= ction 2.10

2.10. =A0Interface

=A0 The following text describes the interface description of the
= =A0 agent_login messages.[I-D.ietf-vwrap-type-system]

=A0 ; authent= icators

=A0 ; hashed password authenticator

=A0 &authen= ticator =3D {
=A0 =A0 type: 'hash', =A0 =A0 =A0 =A0 =A0 ; identifies this as &qu= ot;hashed" type
=A0 =A0 algorithm: 'sha256', =A0 = =A0;
=A0 =A0 secret: binary =A0 =A0 =A0 =A0 =A0; hash of salt prepended= to the password;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 ; =A0 s =3D h( '$1$' | pw )
=A0 }

=A0 ; challenge response style authenticator

=A0 &am= p;authenticator =3D {
=A0 =A0 type: 'challenge', =A0 =A0 =A0; i= dentifies this as a "challenge response"
=A0 =A0 algorithm: &= #39;sha256', =A0 =A0;
=A0 =A0 salt: binary, =A0 =A0 =A0 =A0 =A0 ; optional - default is 0x24, 0x= 31, 0x24
=A0 =A0 secret: binary =A0 =A0 =A0 =A0 =A0; hash of the salt p= repended to password
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 ; =A0 s =3D h( salt | h( '$1$' | pw ) )
=A0 }

=A0 ; PKCS#5 PBKDF2 style authenticator

=A0 &aut= henticator =3D {
=A0 =A0 type: 'pkcs5pbkdf2', =A0 =A0; identifi= es authenticator as PKCS#5 PBKDF2
=A0 =A0 algorithm: string, =A0 =A0 = =A0; identifier for hash ('sha256')
=A0 =A0 salt: binary, =A0 =A0 =A0 =A0 =A0 ; optional - default is 0x24, 0x= 31, 0x24
=A0 =A0 count: int, =A0 =A0 =A0 =A0 =A0 =A0 ; optional - 1 use= d if not present
=A0 =A0 secret: binary =A0 =A0 =A0 =A0 =A0; hash of th= e salt prepended to password
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 ; s =3D pbkdf2( h('$1$' |pw),salt,count,128)
=A0 }

=A0 ; Capability

=A0 &authenticator =3D {
= =A0 =A0 type: 'capability' =A0 =A0 =A0; identifies "capabilit= y" authentication
=A0 }

=A0 ; Transport

=A0 &a= uthenticator =3D {
=A0 =A0 type: 'transport', =A0 =A0 =A0; identifies "transport= based" auth
=A0 }

=A0 ; request

=A0 &cred= ential =3D {
=A0 =A0 account_name: string,
=A0 =A0 authenticator: &= amp;authenticator ; 'hash' 'challenge' or 'pkcs5pbkdf2&= #39;
=A0 }

=A0 ; response

=A0 ; successful response

=A0= &response =3D {
=A0 =A0 condition: 'success',
=A0 =A0 = agent_seed_capability: uri =A0 =A0; URL of the agent seed cap
=A0 }
=
=A0 ; authentication failure

=A0 &response =3D {
=A0 =A0 condition: 'key',
=A0 = =A0 salt: binary, =A0 =A0 =A0 =A0 =A0 =A0; optional - salt for challenge an= d PKCS5
=A0 =A0 count: int, =A0 =A0 =A0 =A0 =A0 =A0 =A0; optional - ite= ration count for PKCS5
=A0 =A0 duration: int =A0 =A0 =A0 =A0 =A0 =A0; o= ptional - the duration of the validity
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0; period of sal= t and count values in
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0; seconds
=A0 }

=A0 ; maintenance "non success&= quot;

=A0 &response =3D {
=A0 =A0 condition: 'maintenan= ce',
=A0 =A0 maintenance_capability: uri, =A0; URL of the maintenance cap
= =A0 =A0 completion: int =A0 =A0 =A0 =A0 =A0 =A0 =A0 ; estimate for maintena= nce duration
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 ; (in seconds)
=A0 }

=A0 ; administrative failure
=A0 &response =3D {
=A0 =A0 condition: 'intervention',=
=A0 =A0 message: uri =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ; a URI with huma= n-readable text
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0; explaining what the user must do to
=A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0; continue
=A0 }

=A0 ; non-specific error

=A0 &response =3D {
= =A0 =A0 condition: 'nonspecific',
=A0 =A0 message: string =A0 = =A0 =A0 =A0 =A0 =A0 =A0; a string describing the failure
=A0 }

= =A0 ; resource definition

=A0 %% agent_login
=A0 -> &credential
=A0 <- &respon= se

the new section 4

4. =A0Security Considerations
=A0 RFC 3552 [RFC3552] describes several aspects to use when evaluat= ing
=A0 the security of a specification or implementation. =A0We believe most<= br> =A0 common security concerns users of this specification will encounter=
=A0 are more appropriately considered as transport, network or link la= yer
=A0 issues. =A0However, the following "application security" iss= ues should
=A0 be considered.

=A0 A previous version of this= document specified the use of the MD5
=A0 cryptographic hash function = [RFC1321]. =A0Its use has been deprecated
=A0 and MUST NOT be used with VWRAP agent_login requests.

=A0 = The use of the hashed password authenticator could result in a replay
= =A0 attack if not used in conjunction with an appropriate confidentiality =A0 preserving transport. =A0Implementations using the hashed password
=A0 authenticator SHOULD utilize appropriate encryption schemes such as
=A0=A0TLS [RFC5246] or S/MIME [RFC3851].

-ch= eers
-meadhbh

--
meadhbh hamrick * it's pro= nounced "maeve"
@OhMeadhbh * h= ttp://meadhbh.org/ * OhMeadhbh@g= mail.com

--0016e65bba62e1e6f3048ad05b0e-- From ohmeadhbh@gmail.com Wed Jul 7 12:09:46 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43E783A684C for ; Wed, 7 Jul 2010 12:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.649, 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 2BPFDR7u0ZRA for ; Wed, 7 Jul 2010 12:09:44 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 822083A6836 for ; Wed, 7 Jul 2010 12:09:44 -0700 (PDT) Received: by qyk1 with SMTP id 1so2558007qyk.10 for ; Wed, 07 Jul 2010 12:09:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=TNbCSGtQtTIEf50ghTaWOhANyWnoc910ZfboBOJ+XkY=; b=HJNoYWtNaZX5ZUcg9usaWfObeKHHF4bGIeQXUKDwBnNe91kegxqNuVG9VGfTQOwiAU a2VuImo+Q+pzELR3vxcSGiudm01VTmx/N0Ftk+FmUBGWQiA6qYHMxnQ1NhfP6moXE6TD kBcLvhSyAqHdyNBB8gSVM6VKigYcY/fSZsKBU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=JmGUZg948CIL9rMCXbMuKpPiwHu2LV8BvDKmjjxoawZmkaB5wE0zkwL0AhYZWAHmrp v7MVlzaEF7ccMneDF2SKAHqNdkwnqReIeazmj8nyj/4e2YOspmUZBN3OGPxNXFcipZoZ Go1mV7KUBrXd4ySyqGXvPPOxjn28o+INSvTkU= Received: by 10.224.65.89 with SMTP id h25mr3837803qai.163.1278529783194; Wed, 07 Jul 2010 12:09:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.185.73 with HTTP; Wed, 7 Jul 2010 12:09:23 -0700 (PDT) From: Meadhbh Hamrick Date: Wed, 7 Jul 2010 12:09:23 -0700 Message-ID: To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=00c09f82c9b38fed82048ad0e93d Subject: [vwrap] auth draft todo.. X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 19:09:46 -0000 --00c09f82c9b38fed82048ad0e93d Content-Type: text/plain; charset=ISO-8859-1 so... is it my imagination or is the auth draft starting to come together? but there are still a few todo's left. i'm going to be working on them in the near future, and will publish another draft after the f2f later this month. (did we decide if there was going to be a VWRAP f2f this time around???) anyway... here's a list of things left to do on the auth draft: 1. add trust model section - mea culpa. i should have finished this earlier. expect another email about the trust model. the linden grid, opensim grid + services, standalone and tourist models are diverse enough, i want to make sure that any trust model documentation supports each of these use cases. 2. make SHA384 an option for authenticators ??? - so if you google "suite b", you can read about the two hash functions that the NSA thinks are copacetic for non-top-secret but sensitive government use. these include SHA-256 and SHA-384. right now the draft only says SHA-256. CNSSP-15 tells us that SHA-384 is really only there to generate parameters for 384 bit ECC crypto primitives. but i wonder if there's anyone out there in fed-space that would require SHA-384 for virtual worlds use? if anyone out there knows of such a requirement, please let me know and i'll add SHA-384 as an option to this draft. otherwise, i recommend we support ONLY SHA256 until we're all comfortable with it's implementation and deployment. 3. better description of the difference between transport and application layer authentication - okay... this is something that kinda throws people, so lemme mention it here. i would also like to write a blurb about it in the next draft of the auth spec. ultimately what we're trying to do with user auth is for a client to demonstrate their authorization to use sensitive data regarding a user's virtual world agent. this usually involves authentication; having the client prove they're in possession of a secret shared between the client and the auth server. so far, so good, right? i mean. no one disputes this, right? where things get interesting is when we start to rely on transport-based authentication. HTTP basic and digest auth identifies and authenticates a user at the HTTP transport layer. but what if we wanted to carry some sensitive payload over XMPP or RTP? we probably shouldn't rely on HTTP digest auth in those cases (and besides, HTTP digest auth is essentially broken unless carried over HTTPS.) and speaking of TLS, what are we authenticating when we authenticate a cert chain? you're not authenticating an authentication service, you're authenticating the host it's running on. this is usually close enough, but i'm nervous about when services move into the cloud and start migrating around to different hosts. (besides TLS is usually only configured to authenticate the server, not the client.) in the "real world" client auth in TLS usually comes from doing HTTP auth or some app layer something-or-other (like possession of session cookie) over HTTP over TLS. or you can use client certificates. i love client certs, but then again i used to work for a company that sold a cert issuing system. while i would love to sell you a PKI system, i'll be the first to admit, it's not the be-all, end-all to authentication that some peeps have said it is in the last couple of decades. besides, client certs are generally used to authenticate the client's host. so when the user moves to a new machine, no more TLS client cert auth. unless they're using smart cards. don't get me started about smart cards. we're not requiring people to use smart cards. and then there's the issue of proxy authentication. a few of us use the interwebs with proxies you have to provide credentials to. do a google search on this! it's true! actually.. i think a lot of HTTP proxy authentication is used in situations where services are composed over primitive service busses and use proxy auth as a first line of defense or as a way to integrate with legacy password / username systems. but i guess what i'm saying is... it's entirely possible we'll be required to authenticate a client to an authentication service in an environment where HTTP(S) based auth is not appropriate. in these cases, we'll probably find that the VWRAP message traffic is going over infrastructure where the transport auth is used for some other purpose, or it's not available to the developer (think of a web app fronted by a HTTPS accellerator that strips out TLS and HTTP auth info.) and this is why we have authentication info INSIDE the application layer message flows. 'cause you're authenticating an application component (the client) with another application component (the auth server.) sometimes you get lucky and you can re-use your transport auth, but not always. and this is kind of what i wanted to put in the draft... "sometimes you can use previously established transport based authentication, but sometimes you can't." -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com --00c09f82c9b38fed82048ad0e93d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable so... is it my imagination or is the auth draft starting to come together?<= div>
but there are still a few todo's left. i'm going= to be working on them in the near future, and will publish another draft a= fter the f2f later this month. (did we decide if there was going to be a VW= RAP f2f this time around???)

anyway... here's a list of things left to do on the= auth draft:

1. add trust model section - mea culp= a. i should have finished this earlier. expect another email about the trus= t model. the linden grid, opensim grid + services, standalone and tourist m= odels are diverse enough, i want to make sure that any trust model document= ation supports each of these use cases.

2. make SHA384 an option for authenticators ??? - so if= you google "suite b", you can read about the two hash functions = that the NSA thinks are copacetic for non-top-secret but sensitive governme= nt use. these include SHA-256 and SHA-384. right now the draft only says SH= A-256. CNSSP-15 tells us that SHA-384 is really only there to generate para= meters for 384 bit ECC crypto primitives. but i wonder if there's anyon= e out there in fed-space that would require SHA-384 for virtual worlds use?= if anyone out there knows of such a requirement, please let me know and i&= #39;ll add SHA-384 as an option to this draft. otherwise, i recommend we su= pport ONLY SHA256 until we're all comfortable with it's implementat= ion and deployment.

3. better description of the difference between transpo= rt and application layer authentication - okay... this is something that ki= nda throws people, so lemme mention it here. i would also like to write a b= lurb about it in the next draft of the auth spec. ultimately what we're= trying to do with user auth is for a client to demonstrate their authoriza= tion to use sensitive data regarding a user's virtual world agent. this= usually involves authentication; having the client prove they're in po= ssession of a secret shared between the client and the auth server.=A0

so far, so good, right? i mean. no one disputes this, r= ight?

where things get interesting is when we star= t to rely on transport-based authentication. HTTP basic and digest auth ide= ntifies and authenticates a user at the HTTP transport layer. but what if w= e wanted to carry some sensitive payload over XMPP or RTP? we probably shou= ldn't rely on HTTP digest auth in those cases (and besides, HTTP digest= auth is essentially broken unless carried over HTTPS.)

and speaking of TLS, what are we authenticating when we= authenticate a cert chain? you're not authenticating an authentication= service, you're authenticating the host it's running on. this is u= sually close enough, but i'm nervous about when services move into the = cloud and start migrating around to different hosts. (besides TLS is usuall= y only configured to authenticate the server, not the client.)

in the "real world" client auth in TLS usuall= y comes from doing HTTP auth or some app layer something-or-other (like pos= session of session cookie) over HTTP over TLS. or you can use client certif= icates. i love client certs, but then again i used to work for a company th= at sold a cert issuing system. while i would love to sell you a PKI system,= i'll be the first to admit, it's not the be-all, end-all to authen= tication that some peeps have said it is in the last couple of decades. bes= ides, client certs are generally used to authenticate the client's host= . so when the user moves to a new machine, no more TLS client cert auth. un= less they're using smart cards. don't get me started about smart ca= rds. we're not requiring people to use smart cards.

and then there's the issue of proxy authentication.= a few of us use the interwebs with proxies you have to provide credentials= to. do a google search on this! it's true! actually.. i think a lot of= HTTP proxy authentication is used in situations where services are compose= d over primitive service busses and use proxy auth as a first line of defen= se or as a way to integrate with legacy password / username systems.

but i guess what i'm saying is... it's entirely= possible we'll be required to authenticate a client to an authenticati= on service in an environment where HTTP(S) based auth is not appropriate. i= n these cases, we'll probably find that the VWRAP message traffic is go= ing over infrastructure where the transport auth is used for some other pur= pose, or it's not available to the developer (think of a web app fronte= d by a HTTPS accellerator that strips out TLS and HTTP auth info.)

and this is why we have authentication info INSIDE the = application layer message flows. 'cause you're authenticating an ap= plication component (the client) with another application component (the au= th server.) sometimes you get lucky and you can re-use your transport auth,= but not always.

and this is kind of what i wanted to put in the draft..= . "sometimes you can use previously established transport based authen= tication, but sometimes you can't."

-cheers
-meadhbh
--
meadhbh hamrick * it's pronounced "m= aeve"
@OhMeadhbh * http://meadhbh.o= rg/ * OhMeadhbh@gmail.com
--00c09f82c9b38fed82048ad0e93d-- From bobby@sharedrealm.com Wed Jul 7 17:59:31 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38BB03A6781 for ; Wed, 7 Jul 2010 17:59:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVOvD769m4Ku for ; Wed, 7 Jul 2010 17:59:30 -0700 (PDT) Received: from mail.neoawareness.com (ns2.sharedrealm.com [IPv6:2001:470:1f05:4f4::13]) by core3.amsl.com (Postfix) with ESMTP id E59EC3A677C for ; Wed, 7 Jul 2010 17:59:29 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=[10.200.0.30]) by mail.neoawareness.com with esmtpa (Exim 4.69) (envelope-from ) id 1OWfSe-0006Tl-Ej for vwrap@ietf.org; Wed, 07 Jul 2010 17:59:32 -0700 From: "Robert G. Jakabosky" To: vwrap@ietf.org Date: Wed, 7 Jul 2010 17:59:22 -0700 User-Agent: KMail/1.9.9 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201007071759.22660.bobby@sharedrealm.com> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bobby@sharedrealm.com X-SA-Exim-Scanned: No (on mail.neoawareness.com); SAEximRunCond expanded to false Subject: Re: [vwrap] adding transport and capability auth types, removing MD5 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 00:59:31 -0000 On Wednesday 07, Meadhbh Hamrick wrote: > > 2.3.2. Hashed Password Authenticator > > *When a hashed password is used as an authenticator, the string '$1$' > is prepended to the UTF-8 encoding of the password and processed with > the SHA256 cryptographic hash function [sha256]. This revision of > the Virtual World Region Agent Protocol specification requires the > use of SHA256 with the hashed password authenticator. It also > requires the presence of the algorithm key, and that the value of > this key be the string 'sha256'. Note that future versions of this > specification may ALLOW or REQUIRE the use of other cryptographic > hash functions.* > > > The use of the hashed password authenticator could result in a replay > attack if not used in conjunction with an appropriate confidentiality > preserving transport. Implementations using the hashed password > authenticator SHOULD utilize appropriate encryption schemes such as > TLS [RFC5246] or S/MIME [RFC3851]. > What use is the "Hashed Password Authenticator", if the transport needs to be encrypted? That SHOULD needs to be a REQUIRED. If an attacker picks up the hashed password even once they will be able to login to the account any time they want, even if the service later only allows the use of the "Challenge-Response Authenticator". Since the same hashed password can be combined with the challenge salt. I think the "Hashed Password Authenticator" needs to be replaced with a "Password Authenticator" that REQUIRES the use of an encrypted transport and sends the password instead of a hashed password. Websites that have login forms use HTTPS to protect the user's password. The browser doesn't send a hashed password to the server. The use of password hashing on websites is to protect the password stored in a database encase some someone hacks the site and gets a copy of the password table. That hashing is done on the server-side not the client-side. A "Password Authenticator" would also allow companies like LindenLab to continue to work with the md5 hashed passwords stored in their database. It would also allow companies in the future to migrate (i.e. rehash) the passwords stored in their database when it comes time to replace a broken hash algorithm. -- Robert G. Jakabosky From ohmeadhbh@gmail.com Wed Jul 7 19:52:40 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 199713A6890 for ; Wed, 7 Jul 2010 19:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433, 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 hGD-QJ7-4qKR for ; Wed, 7 Jul 2010 19:52:38 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 832433A67B7 for ; Wed, 7 Jul 2010 19:52:35 -0700 (PDT) Received: by vws14 with SMTP id 14so497422vws.31 for ; Wed, 07 Jul 2010 19:52:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=vHeVq/Js7fQxluPqxgGofkVl1mwwB1ExLxXuIpmzcKA=; b=dnkMu0tX9NWT5SuGmEEk8Dd5PoMzZJ3XcKOwm7pbtKH5ts/RZvxTUM3hgGTv0aXBpD JP9K8IwI95dsNDX6nrix+0JF2zMHgjoVW2483LwSpEF0aBAOJzEF28KN43C3utmi5xwb JcfLIruSdvE6+BOnz692Zjj8ASza31cs1bSjw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=ja0bNh8Z+6G8naNj2dhzz1cB4M52oNunwi0pUH5RlkZW9YhomMZzfNmOdzGJgvjfEx 6fQOdAJ/SKO/eO4P3tNtLBo4PHLasYd9NvznvLV7/KeSA2g726/dm7qElvD4VWHWQPwG 9vexWFR7xj4ETo13AqPvGSgNU3+Y/3EGEOPNQ= Received: by 10.229.220.73 with SMTP id hx9mr4576588qcb.143.1278557556054; Wed, 07 Jul 2010 19:52:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.185.73 with HTTP; Wed, 7 Jul 2010 19:52:14 -0700 (PDT) In-Reply-To: <201007071759.22660.bobby@sharedrealm.com> References: <201007071759.22660.bobby@sharedrealm.com> From: Meadhbh Hamrick Date: Wed, 7 Jul 2010 19:52:14 -0700 Message-ID: To: "Robert G. Jakabosky" Content-Type: multipart/alternative; boundary=001636284748f41c37048ad7600f Cc: vwrap@ietf.org Subject: Re: [vwrap] adding transport and capability auth types, removing MD5 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 02:52:40 -0000 --001636284748f41c37048ad7600f Content-Type: text/plain; charset=ISO-8859-1 okay... a little background on hashed authenticators... the original hashed authenticator was going to be used to replicate SL's functionality of sending the non-salted, non-iterated, hash of a long-term password. but we wanted to have something better, so someone came up with the challenge response scheme for use with the summer 2008 interop trial (thought honestly, i don't think it was deployed.) then i came up with the idea of using the PKCS#5 password based key derivation function (PBKDF.) and then the world went on until john hurliman and i were both trying to figure out how to leverage OpenID and OAuth in VWRAP. that's where the CALM message stuff came from. originally we were going to have the CALM message include a "one time use" shared secret that the web-auth system would tell the client and tell the VWRAP auth service about. then john came up with the idea of putting the agent_login resource behind a web capability, so he could just use proof of possession of the capability as authorization to log in. so now we're writing standards docs and we're talking about layering VWRAP application layer object access across at least three different transports: HTTP(S), XMPP and RTP. granted, it's probably unlikely that people are going to attempt to send login credentials over RTP, but i used to work with game programmers, so i've seen some pretty crazy things. so the reason we say SHOULD instead of MUST is that we don't know if the deployer will secure their network with IPSec, a Link Encryptor or TLS. HTTPS requires the use of HTTP as a transport, and we're not entirely certain that everyone wants to do that. so in the proud tradition of internet standards everywhere, we will allow implementers to shoot themselves in the foot if they really feel they need to. On Wed, Jul 7, 2010 at 5:59 PM, Robert G. Jakabosky wrote: > On Wednesday 07, Meadhbh Hamrick wrote: > > > > > > 2.3.2. Hashed Password Authenticator > > > > *When a hashed password is used as an authenticator, the string '$1$' > > is prepended to the UTF-8 encoding of the password and processed with > > the SHA256 cryptographic hash function [sha256]. This revision of > > the Virtual World Region Agent Protocol specification requires the > > use of SHA256 with the hashed password authenticator. It also > > requires the presence of the algorithm key, and that the value of > > this key be the string 'sha256'. Note that future versions of this > > specification may ALLOW or REQUIRE the use of other cryptographic > > hash functions.* > > > > > > > > > The use of the hashed password authenticator could result in a replay > > attack if not used in conjunction with an appropriate confidentiality > > preserving transport. Implementations using the hashed password > > authenticator SHOULD utilize appropriate encryption schemes such as > > TLS [RFC5246] or S/MIME [RFC3851]. > > > > What use is the "Hashed Password Authenticator", if the transport needs to > be > encrypted? That SHOULD needs to be a REQUIRED. If an attacker picks up > the > hashed password even once they will be able to login to the account any > time > they want, even if the service later only allows the use of > the "Challenge-Response Authenticator". Since the same hashed password can > be combined with the challenge salt. > > I think the "Hashed Password Authenticator" needs to be replaced with > a "Password Authenticator" that REQUIRES the use of an encrypted transport > and sends the password instead of a hashed password. Websites that have > login forms use HTTPS to protect the user's password. The browser doesn't > send a hashed password to the server. The use of password hashing on > websites is to protect the password stored in a database encase some > someone > hacks the site and gets a copy of the password table. That hashing is done > on the server-side not the client-side. > > A "Password Authenticator" would also allow companies like LindenLab to > continue to work with the md5 hashed passwords stored in their database. > It > would also allow companies in the future to migrate (i.e. rehash) the > passwords stored in their database when it comes time to replace a broken > hash algorithm. > > -- > Robert G. Jakabosky > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --001636284748f41c37048ad7600f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
okay... a little background on hashed authenticators...

the original hashed authenticator was going to be used to r= eplicate SL's functionality of sending the=A0non-salted, non-iterated,= =A0hash of a long-term password.

but we wanted to have something better, so someone came= up with the challenge response scheme for use with the summer 2008 interop= trial (thought honestly, i don't think it was deployed.)

then i came up with the idea of using the PKCS#5 password ba= sed key derivation function (PBKDF.)

and then the = world went on until john hurliman and i were both trying to figure out how = to leverage OpenID and OAuth in VWRAP. that's where the CALM message st= uff came from. originally we were going to have the CALM message include a = "one time use" shared secret that the web-auth system would tell = the client and tell the VWRAP auth service about. then john came up with th= e idea of putting the agent_login resource behind a web capability, so he c= ould just use proof of possession of the capability as authorization to log= in.

so now we're writing standards docs and we're t= alking about layering VWRAP application layer object access across at least= three different transports: HTTP(S), XMPP and RTP. granted, it's proba= bly unlikely that people are going to attempt to send login credentials ove= r RTP, but i used to work with game programmers, so i've seen some pret= ty crazy things.

so the reason we say SHOULD instead of MUST is that we = don't know if the deployer will secure their network with IPSec, a Link= Encryptor or TLS. HTTPS requires the use of HTTP as a transport, and we= 9;re not entirely certain that everyone wants to do that.

so in the proud tradition of internet standards everywh= ere, we will allow implementers to shoot themselves in the foot if they rea= lly feel they need to.

On Wed, Jul= 7, 2010 at 5:59 PM, Robert G. Jakabosky <bobby@sharedrealm.com> wrote:
On Wednesday 07, Meadhbh Hamrick wrote:

<snip>
>
> 2.3.2. =A0Hashed Password Authenticator
>
> =A0 *When a hashed password is used as an authenticator, the string &#= 39;$1$'
> =A0 is prepended to the UTF-8 encoding of the password and processed w= ith
> =A0 the SHA256 cryptographic hash function [sha256]. =A0This revision = of
> =A0 the Virtual World Region Agent Protocol specification requires the=
> =A0 use of SHA256 with the hashed password authenticator. =A0It also > =A0 requires the presence of the algorithm key, and that the value of<= br> > =A0 this key be the string 'sha256'. =A0Note that future versi= ons of this
> =A0 specification may ALLOW or REQUIRE the use of other cryptographic<= br>
> =A0 hash functions.*
>

<snip>

>
> =A0 The use of the hashed password authenticator could result in a rep= lay
> =A0 attack if not used in conjunction with an appropriate confidential= ity
> =A0 preserving transport. =A0Implementations using the hashed password=
> =A0 authenticator SHOULD utilize appropriate encryption schemes such a= s
> =A0 TLS [RFC5246] or S/MIME [RFC3851].
>

What use is the "Hashed Password Authenticator", if the tra= nsport needs to be
encrypted? =A0That SHOULD needs to be a REQUIRED. =A0If an attacker picks u= p the
hashed password even once they will be able to login to the account any tim= e
they want, even if the service later only allows the use of
the "Challenge-Response Authenticator". =A0Since the same hashed = password can
be combined with the challenge salt.

I think the "Hashed Password Authenticator" needs to be replaced = with
a "Password Authenticator" that REQUIRES the use of an encrypted = transport
and sends the password instead of a hashed password. =A0Websites that have<= br> login forms use HTTPS to protect the user's password. =A0The browser do= esn't
send a hashed password to the server. =A0The use of password hashing on
websites is to protect the password stored in a database encase some someon= e
hacks the site and gets a copy of the password table. =A0That hashing is do= ne
on the server-side not the client-side.

A "Password Authenticator" would also allow companies like Linden= Lab to
continue to work with the md5 hashed passwords stored in their database. = =A0It
would also allow companies in the future to migrate (i.e. rehash) the
passwords stored in their database when it comes time to replace a broken hash algorithm.

--
Robert G. Jakabosky
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--001636284748f41c37048ad7600f-- From ohmeadhbh@gmail.com Thu Jul 15 14:02:12 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 327F23A67F5 for ; Thu, 15 Jul 2010 14:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.428 X-Spam-Level: X-Spam-Status: No, score=-0.428 tagged_above=-999 required=5 tests=[AWL=-0.429, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUA1JwAKSeM0 for ; Thu, 15 Jul 2010 14:02:05 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 207883A69B5 for ; Thu, 15 Jul 2010 14:02:05 -0700 (PDT) Received: by gwj19 with SMTP id 19so820092gwj.31 for ; Thu, 15 Jul 2010 14:02:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type:content-transfer-encoding; bh=moTCELHOKUKbqzwfuR1VVCkqNaxq3MowU2rxQ5I9YHc=; b=NiSdAybzDPX9zLk1x/yCvOqZO2vYAy5oKGviXB0Rsa5LGt+jMMFYAmdjjEPTpqrPVM Cnq3GHa1tCUw5JenP3MQHGDGC7KZslF9JKquHw8C4k/SREAM1zIbVf4Uvj3FU55DxaCn KcNWN+fOPXOfv3Lo7yEv/jf6oLZ+ONyZl657E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; b=qk8uk1+4T+f+3EdpoZTlgSEpT0vibK98FZNh7Oct1V5E2f2mV4x/2DsUUs2leEH0XT MhYbnHMFLLPTczEki5Xgl5I+ZpHvUMRCvDeaQ9h0Cp9b4LGtPwViq/BqFkuFy0vmO0dt 41YNBrC9DdRvCt0EFhR4M7EaBUfkJT10o+S10= Received: by 10.150.65.13 with SMTP id n13mr481243yba.185.1279227733131; Thu, 15 Jul 2010 14:02:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.13.225 with HTTP; Thu, 15 Jul 2010 14:01:53 -0700 (PDT) From: Meadhbh Hamrick Date: Thu, 15 Jul 2010 14:01:53 -0700 Message-ID: To: vwrap@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [vwrap] thinking about LLIDL and the future X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 21:02:12 -0000 hey peeps, i've been pondering LLIDL for a bit now, and there are some things about it that really stick in my craw. i put together a blog post about it, but wanted to replicate it here on the list. from http://blog.meadhbh.org/2010/07/abstract-resource-definitions-vs-llidl= .html so i've been noodling on LLIDL and LLSD for a couple years now, and i think i've figured something out. i like the concept of an "abstract resource definition" a lot more than i like an "interface description language." (if you have no idea what i'm talking about, you may want to read my previous blog post "VWRAP Essentials : an abstract type system? hunh?." advanced students can take a look at the internet draft: draft-ieft-vwrap-type-system-00.) the background the objective of the abstract type system is simple and well defined: it provides system independent type semantics for structured data developed by protocol designers. that is, it defines types that are common to popular implementation languages. and it does it in a way that developers know the details of the types. like whether integers are 32 or 64 bits and whether radix 10 is supported in floats and so forth. the LLSD abstract type system describes how a small set of fundamental types work so implementers know how their "concretized" implementations should behave. and this is a good thing. the problem but after having mulled LLIDL around, i'm starting to see some issues with it. the main problem i have with it is that the interface is hopelessly entangled with the resource it describes. that is, you can't define an abstract resource without defining a method of access. for example, the current spec describes a way to say something like this: &info =3D { name : string, status_uri : uri enroll_uri : uri login_uri : uri } %% site_info << &info in this example, the &info named type describes a structure that includes a string and three URIs. but the only context you can use the &info named type in is when you use a HTTP GET to access it. i think this is wrong. it's wrong because it links the declaration of the structure of a resource with the transport used to access it. i have no problem with accessing resources over HTTP(S), but i do have a problem with ONLY accessing them over HTTP(S). i think there's sufficient interest in the VWRAP working group to support the concept of making resource definition and access orthogonal. i would personally want to be able to have the option of using XMPP and (S)RTP when characteristics of those protocols are advantageous. but i don't want to have to create a new data definition language every time i want to go access a resource over a new transport. furthermore, there are still open questions regarding content negotiation over HTTP(S). suzy deffeyes, john hurliman and i have reached a rough consensus on how to handle content negotiation, but we need to put it in an internet draft so other people can comment on it and implement it without having to refer to random email archives and IRC logs. a proposed solution i propose we layer an abstract resource definition on top of the abstract type system. the abstract resource definition can then be used to describe a transfer syntax (aka serialization scheme) for resources. we can then describe how each transport (HTTP(S), XMPP, etc.) carries serialized resource data. we can then describe interaction semantics independent of resource definition. the benefit of this is it makes it easier to create systems that are transport-neutral. some of the lessons we learned from Second Life=99 and the Linden Lab Legacy Protocol are that there's a LOT of stuff that's not "real time" data. I suspect that moving forward, we'll discover there are a lot of interactions that are modeled with the request-response pattern. i am proposing a solution that would offer deployers and protocol designers the ability to describe a resource without describing the method in which it is accessed. more details this proposal describes five components: the abstract type system, the abstract resource definition, the transfer syntax, the abstract interaction definition and the transfer mapping. abstract type system as mentioned above, the abstract type system defines a core set of types and type behavior. types are intended to be "concretized" in programming languages like C, Java, Python, whatever. we create an "abstract" type system so we're free to define the type behavior we want while not being tied to type behavior of a particular implementation language. individual implementers are responsible for ensuring that type semantics are consistent with the spec. for example, imagine you were developing an application using an embedded 8 bit microprocessor and there was a protocol flow that involved incrementing an integer. a client might send you a 32 bit integer, assuming you would increment it. you would be responsible for modeling the behavior of a 32 bit integer despite the fact your micro-controller probably only natively knows about 16 bit ints. abstract resource definition the abstract resource definition is sort of like the abstract type system for collections. we define a resource as being either an individual item (a boolean, integer, etc.) or we define it as being a map or an array. the abstract resource definition system allows protocol developers to define the "shape" of resources. but because they are dynamic, implementations must allow for the type of a resource to differ from it's definition and for elements in map to be added and removed. for example, you may want to define the following resource to describe an user logged into a system: RESOURCE agent { name string, identifier uri, current_location uri } the abstract resource definition is used to group named data elements together into a dynamic structure. these structures will later be used by the abstract interaction definition. transfer syntax (aka serialization scheme) these are basically the three serialization schemes defined in the type-system draft: XML, JSON and Binary. they define how structured data is serialized into an octet string in preparation for transmission across a network. for example, the resource defined above might be serialized like this: name Meadhbh Oh identifier http://world.secondlife.com/resident/6e7477a7-2de5-4660-bc83-4a47096a= 18f0 current_location http://world.secondlife.com/place/65f385f0-691c-5755-9ef0-15f3bb05c8b= 7 abstract interaction definition LLIDL currently defines access verb sets that are tied to HTTP verbs. if we want to be able to access resources using multiple transports, this is wrong. i propose we define an abstract interaction description "language" that is later mapped to a particular transport. i propose we have five "abstract" verbs: CREATE, READ, UPDATE, DELETE and EVENT. the first four should be pretty straight forward. They're used to create resources, read and write them and then maybe delete them. the last verb, EVENT, is used to define a resource an entity may receive without requesting it. things like object updates, incoming message session requests, etc. transport mapping the transport mapping maps abstract verbs from the abstract interaction description language to concretized protocol flows in the transport. so, for instance, you may use this to say that CREATE abstract access methods map to a POST verb in HTTP or that an EVENT message is delivered via the HTTP event queue. conclusion i'm going to wrap as much of this as i can into an internet draft and create some example code. but i figured i would get this idea out there so people can comment on it. just lemme know what you think... -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com From morgaine.dinova@googlemail.com Fri Jul 16 03:07:36 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A726A3A67F7 for ; Fri, 16 Jul 2010 03:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.31 X-Spam-Level: X-Spam-Status: No, score=-0.31 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZV990Obe5oS for ; Fri, 16 Jul 2010 03:07:33 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 3589F3A6827 for ; Fri, 16 Jul 2010 03:07:33 -0700 (PDT) Received: by eyb7 with SMTP id 7so483174eyb.31 for ; Fri, 16 Jul 2010 03:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=6IMAgw/XbAArwyozMAwzLSJeOY6IEft9znseCi2bqXg=; b=PcEOF0OORygc51tWAj+5YqvaVnEOhFjI91EDvLDvC3EsaHWOjHt6MF/Josc1+Pdm0G I6jxff0/ZYtPSPnoTlxqSkQCnhKyFaLvjXMgleHSvw7ZvDqRa5zbJZdwYHMOnN+Yxky2 SDKcGU1P9WfTIEta8kH7MD01VrYZU/GujZUVU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=b8s06iAf5a8DLFYY821hYkTSKE08ynPB/mCCDOeaWFFwaou0TEqMbxg2FxgQ+TtNzV uBxGWYnRl+cB2lowDX9wcwbNKV2WT9h6TQcMI/gtAWd77vV7SNynXIgO56xUxCvcYgGb uyPTpHwPtV1MarrYzjY+dCAnBiQkbBnerDKlQ= MIME-Version: 1.0 Received: by 10.216.168.198 with SMTP id k48mr584686wel.105.1279274860980; Fri, 16 Jul 2010 03:07:40 -0700 (PDT) Received: by 10.216.139.215 with HTTP; Fri, 16 Jul 2010 03:07:40 -0700 (PDT) In-Reply-To: References: Date: Fri, 16 Jul 2010 11:07:40 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016367fbad4a8afb7048b7e63d9 Subject: Re: [vwrap] thinking about LLIDL and the future X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 10:07:36 -0000 --0016367fbad4a8afb7048b7e63d9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree with the main thrust of Meadhbh's proposal. Defining the "Method Access Delimeters" of LLIDL resources in terms of HTTP operations directly was not generic nor forward looking. The type system draft uses highly HTTP-centric language in the LLIDL section, for example: = " *A LLIDL "Resource" represents information or state maintained by a remote system, accessed via HTTP(S).*" Clearly this is wrong, if our intention is to be transport-agnostic. Likewise, defining the "Method Access Delimeters" of LLIDL in terms of HTTP operations was quite wrong, not to mention that it gave us rather ugly syntax too ("<>" for GET/PUT, "" for GET/PUT/DELETE, and "->" and "<-" for POST). If we're putting LLIDL resources on a sounder, transport-agnostic footing, this is a good opportunity for cleaning up the syntax while we're at it, and making it more flexible. I support the suggestion that we define the 4 CRUD "abstract verbs" CREATE, READ, UPDATE and DELETE as terminals in the LLIDL grammar. This is highly readable, and it is also semantically clean because CRUD operations are disjoint. Note that in client-server protocols, each CRUD operation is usually implemented as two messages, a request message and a response message --- this is relevant below. The proposed 5th verb "EVENT" is more problematic, and I think it's actuall= y incorrect, as it seems to have confused the concepts of "verb" and "message". The reality is that messages received outside of a 2-part synchronous request-response pair usually carry some kind of type information that activates an operation handler at the receiving end. Such operation is enabled by a prior CRUD verb that sets up the session to allow asynchronous messages to be sent and received subsequently. In other words= , EVENT isn't a verb or operation at all, it's an asynchronous response message to a prior verb. This is the situation as I see it: VW protocols are almost always message-based, and they are almost always request-response in nature but th= e "response" can comprise an unlimited sequence of response messages, zero or more. The reason I see it this way is that a truly unsolicited message is actually spam, or worse, an attack packet. All other messages (including asynchronous ones) *were* solicited by some previous request which enabled the sending of asynchronous messages in the first place. This is why I don't see "EVENT" as a resource operation. It's a deferred response message that was emitted after being enabled by some previous CRUD request, and it carries data in response to one of the 4 CRUD operations within it, either implicitly or explicitly. As an example, a client should not receive scenegraph update messages unles= s it has first requested them using a CRUD verb on the appropriate region resource(s). Once it has requested them, they become valid and are processed by the client scenegraph handlers, but if it has not requested them then they are invalid and should never be sent nor received. Indeed, if they *are* received without being requested then they should be processe= d by the error handler. In a text-only client for example, there probably wouldn't even be any scenegraph handlers present in the code. "EVENT" then is not itself a verb that acts on resources. It's an asynchronous response message, part of a sequence of zero or more such messages, and this potentially unlimited sequence of messages is started by one CRUD operation and stopped by another CRUD operation. Notice that the EVENT message can also be a container for CRUD request messages in the reverse direction, but even such container messages obey th= e above rule that they are started by one CRUD verb and stopped by another. In summary, EVENT is not a resource verb but an *asynchronous transport property* of a resource, and if that property is enabled by a CRUD operation, then EVENT messages are emitted under control of that resource. Apart from EVENT, I think that this is a great proposal. Regarding EVENT, = I suggest that we analyze this area further and find a clean way of integrating EVENTS into our resources-based scheme. I'm very interested in this topic. Morgaine. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D On Thu, Jul 15, 2010 at 10:01 PM, Meadhbh Hamrick wrot= e: > hey peeps, > > i've been pondering LLIDL for a bit now, and there are some things > about it that really stick in my craw. i put together a blog post > about it, but wanted to replicate it here on the list. > > from > http://blog.meadhbh.org/2010/07/abstract-resource-definitions-vs-llidl.ht= ml > > so i've been noodling on LLIDL and LLSD for a couple years now, and i > think i've figured something out. i like the concept of an "abstract > resource definition" a lot more than i like an "interface description > language." (if you have no idea what i'm talking about, you may want > to read my previous blog post "VWRAP Essentials : an abstract type > system? hunh?." advanced students can take a look at the internet > draft: draft-ieft-vwrap-type-system-00.) > > the background > > the objective of the abstract type system is simple and well defined: > it provides system independent type semantics for structured data > developed by protocol designers. that is, it defines types that are > common to popular implementation languages. and it does it in a way > that developers know the details of the types. like whether integers > are 32 or 64 bits and whether radix 10 is supported in floats and so > forth. the LLSD abstract type system describes how a small set of > fundamental types work so implementers know how their "concretized" > implementations should behave. and this is a good thing. > > the problem > > but after having mulled LLIDL around, i'm starting to see some issues > with it. the main problem i have with it is that the interface is > hopelessly entangled with the resource it describes. that is, you > can't define an abstract resource without defining a method of access. > for example, the current spec describes a way to say something like > this: > > &info =3D { > name : string, > status_uri : uri > enroll_uri : uri > login_uri : uri > } > > %% site_info << &info > > in this example, the &info named type describes a structure that > includes a string and three URIs. but the only context you can use the > &info named type in is when you use a HTTP GET to access it. i think > this is wrong. > > it's wrong because it links the declaration of the structure of a > resource with the transport used to access it. i have no problem with > accessing resources over HTTP(S), but i do have a problem with ONLY > accessing them over HTTP(S). > > i think there's sufficient interest in the VWRAP working group to > support the concept of making resource definition and access > orthogonal. i would personally want to be able to have the option of > using XMPP and (S)RTP when characteristics of those protocols are > advantageous. but i don't want to have to create a new data definition > language every time i want to go access a resource over a new > transport. > > furthermore, there are still open questions regarding content > negotiation over HTTP(S). suzy deffeyes, john hurliman and i have > reached a rough consensus on how to handle content negotiation, but we > need to put it in an internet draft so other people can comment on it > and implement it without having to refer to random email archives and > IRC logs. > > a proposed solution > > i propose we layer an abstract resource definition on top of the > abstract type system. the abstract resource definition can then be > used to describe a transfer syntax (aka serialization scheme) for > resources. we can then describe how each transport (HTTP(S), XMPP, > etc.) carries serialized resource data. we can then describe > interaction semantics independent of resource definition. > > the benefit of this is it makes it easier to create systems that are > transport-neutral. some of the lessons we learned from Second Life=99 > and the Linden Lab Legacy Protocol are that there's a LOT of stuff > that's not "real time" data. I suspect that moving forward, we'll > discover there are a lot of interactions that are modeled with the > request-response pattern. i am proposing a solution that would offer > deployers and protocol designers the ability to describe a resource > without describing the method in which it is accessed. > > more details > > this proposal describes five components: the abstract type system, the > abstract resource definition, the transfer syntax, the abstract > interaction definition and the transfer mapping. > > abstract type system > > as mentioned above, the abstract type system defines a core set of > types and type behavior. types are intended to be "concretized" in > programming languages like C, Java, Python, whatever. we create an > "abstract" type system so we're free to define the type behavior we > want while not being tied to type behavior of a particular > implementation language. individual implementers are responsible for > ensuring that type semantics are consistent with the spec. > > for example, imagine you were developing an application using an > embedded 8 bit microprocessor and there was a protocol flow that > involved incrementing an integer. a client might send you a 32 bit > integer, assuming you would increment it. you would be responsible for > modeling the behavior of a 32 bit integer despite the fact your > micro-controller probably only natively knows about 16 bit ints. > > abstract resource definition > > the abstract resource definition is sort of like the abstract type > system for collections. we define a resource as being either an > individual item (a boolean, integer, etc.) or we define it as being a > map or an array. the abstract resource definition system allows > protocol developers to define the "shape" of resources. but because > they are dynamic, implementations must allow for the type of a > resource to differ from it's definition and for elements in map to be > added and removed. > > for example, you may want to define the following resource to describe > an user logged into a system: > > RESOURCE agent { > name string, > identifier uri, > current_location uri > } > > the abstract resource definition is used to group named data elements > together into a dynamic structure. these structures will later be used > by the abstract interaction definition. > > transfer syntax (aka serialization scheme) > > these are basically the three serialization schemes defined in the > type-system draft: XML, JSON and Binary. they define how structured > data is serialized into an octet string in preparation for > transmission across a network. for example, the resource defined above > might be serialized like this: > > > "http://home.meadhbh.org/xml/xxdsd/0.1/xxdsd.dtd"> > > name > Meadhbh Oh > identifier > > http://world.secondlife.com/resident/6e7477a7-2de5-4660-bc83-4a47096a18f0 > > current_location > > http://world.secondlife.com/place/65f385f0-691c-5755-9ef0-15f3bb05c8b7 > > > > abstract interaction definition > > LLIDL currently defines access verb sets that are tied to HTTP verbs. > if we want to be able to access resources using multiple transports, > this is wrong. i propose we define an abstract interaction description > "language" that is later mapped to a particular transport. > > i propose we have five "abstract" verbs: CREATE, READ, UPDATE, DELETE > and EVENT. the first four should be pretty straight forward. They're > used to create resources, read and write them and then maybe delete > them. the last verb, EVENT, is used to define a resource an entity may > receive without requesting it. things like object updates, incoming > message session requests, etc. > > transport mapping > > the transport mapping maps abstract verbs from the abstract > interaction description language to concretized protocol flows in the > transport. so, for instance, you may use this to say that CREATE > abstract access methods map to a POST verb in HTTP or that an EVENT > message is delivered via the HTTP event queue. > > conclusion > > i'm going to wrap as much of this as i can into an internet draft and > create some example code. but i figured i would get this idea out > there so people can comment on it. just lemme know what you think... > > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --0016367fbad4a8afb7048b7e63d9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree with the main thrust of Meadhbh's proposal.

Defining the= "Method Access Delimeters" of LLIDL resources in terms of HTTP o= perations directly was not generic nor forward looking.=A0 The type system = draft uses highly HTTP-centric language in the LLIDL section, for example: = "A LLIDL "Resource" represents information or state maint= ained by a remote system, accessed via HTTP(S)."=A0 Clearly this i= s wrong, if our intention is to be transport-agnostic.

Likewise, defining the "Method Access Delimeters" of LLIDL in= terms of HTTP operations was quite wrong, not to mention that it gave us r= ather ugly syntax too ("<>" for GET/PUT, "<x>&qu= ot; for GET/PUT/DELETE, and "->" and "<-" for POS= T).=A0 If we're putting LLIDL resources on a sounder, transport-agnosti= c footing, this is a good opportunity for cleaning up the syntax while we&#= 39;re at it, and making it more flexible.

I support the suggestion that we define the 4 CRUD "abstract verbs= " CREATE, READ, UPDATE and DELETE as terminals in the LLIDL grammar.= =A0 This is highly readable, and it is also semantically clean because CRUD= operations are disjoint.=A0 Note that in client-server protocols, each CRU= D operation is usually implemented as two messages, a request message and a= response message --- this is relevant below.

The proposed 5th verb "EVENT" is more problematic, and I thin= k it's actually incorrect, as it seems to have confused the concepts of= "verb" and "message".=A0 The reality is that messages = received outside of a 2-part synchronous request-response pair usually carr= y some kind of type information that activates an operation handler at the = receiving end.=A0 Such operation is enabled by a prior CRUD verb that sets = up the session to allow asynchronous messages to be sent and received subse= quently.=A0 In other words, EVENT isn't a verb or operation at all, it&= #39;s an asynchronous response message to a prior verb.

This is the situation as I see it:=A0 VW protocols are almost always me= ssage-based, and they are almost always request-response in nature but the = "response" can comprise an unlimited sequence of response message= s, zero or more.=A0 The reason I see it this way is that a truly unsolicite= d message is actually spam, or worse, an attack packet.=A0 All other messag= es (including asynchronous ones) *were* solicited by some previous request = which enabled the sending of asynchronous messages in the first place.

This is why I don't see "EVENT" as a resource operation.= =A0 It's a deferred response message that was emitted after being enabl= ed by some previous CRUD request, and it carries data in response to one of= the 4 CRUD operations within it, either implicitly or explicitly.

As an example, a client should not receive scenegraph update messages u= nless it has first requested them using a CRUD verb on the appropriate regi= on resource(s).=A0 Once it has requested them, they become valid and are pr= ocessed by the client scenegraph handlers, but if it has not requested them= then they are invalid and should never be sent nor received.=A0 Indeed, if= they *are* received without being requested then they should be processed = by the error handler.=A0 In a text-only client for example, there probably = wouldn't even be any scenegraph handlers present in the code.

"EVENT" then is not itself a verb that acts on resources.=A0 = It's an asynchronous response message, part of a sequence of zero or mo= re such messages, and this potentially unlimited sequence of messages is st= arted by one CRUD operation and stopped by another CRUD operation.

Notice that the EVENT message can also be a container for CRUD request = messages in the reverse direction, but even such container messages obey th= e above rule that they are started by one CRUD verb and stopped by another.=

In summary, EVENT is not a resource verb=A0 but an asynchronous tran= sport property of a resource, and if that property is enabled by a CRUD= operation, then EVENT messages are emitted under control of that resource.=

Apart from EVENT, I think that this is a great proposal.=A0 Regarding E= VENT, I suggest that we analyze this area further and find a clean way of i= ntegrating EVENTS into our resources-based scheme.=A0 I'm very interest= ed in this topic.


Morgaine.





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

<= div class=3D"gmail_quote">On Thu, Jul 15, 2010 at 10:01 PM, Meadhbh Hamrick= <ohmeadhbh@gma= il.com> wrote:
hey peeps,

i've been pondering LLIDL for a bit now, and there are some things
about it that really stick in my craw. i put together a blog post
about it, but wanted to replicate it here on the list.

from http://blog.meadhbh.org/2010/07/abstrac= t-resource-definitions-vs-llidl.html

so i've been noodling on LLIDL and LLSD for a couple years now, and i think i've figured something out. i like the concept of an "abstra= ct
resource definition" a lot more than i like an "interface descrip= tion
language." (if you have no idea what i'm talking about, you may wa= nt
to read my previous blog post "VWRAP Essentials : an abstract type
system? hunh?." advanced students can take a look at the internet
draft: draft-ieft-vwrap-type-system-00.)

the background

the objective of the abstract type system is simple and well defined:
it provides system independent type semantics for structured data
developed by protocol designers. that is, it defines types that are
common to popular implementation languages. and it does it in a way
that developers know the details of the types. like whether integers
are 32 or 64 bits and whether radix 10 is supported in floats and so
forth. the LLSD abstract type system describes how a small set of
fundamental types work so implementers know how their "concretized&quo= t;
implementations should behave. and this is a good thing.

the problem

but after having mulled LLIDL around, i'm starting to see some issues with it. the main problem i have with it is that the interface is
hopelessly entangled with the resource it describes. that is, you
can't define an abstract resource without defining a method of access.<= br> for example, the current spec describes a way to say something like
this:

&info =3D {
=A0name : string,
=A0status_uri : uri
=A0enroll_uri : uri
=A0login_uri : uri
}

%% site_info << &info

in this example, the &info named type describes a structure that
includes a string and three URIs. but the only context you can use the
&info named type in is when you use a HTTP GET to access it. i think this is wrong.

it's wrong because it links the declaration of the structure of a
resource with the transport used to access it. i have no problem with
accessing resources over HTTP(S), but i do have a problem with ONLY
accessing them over HTTP(S).

i think there's sufficient interest in the VWRAP working group to
support the concept of making resource definition and access
orthogonal. i would personally want to be able to have the option of
using XMPP and (S)RTP when characteristics of those protocols are
advantageous. but i don't want to have to create a new data definition<= br> language every time i want to go access a resource over a new
transport.

furthermore, there are still open questions regarding content
negotiation over HTTP(S). suzy deffeyes, john hurliman and i have
reached a rough consensus on how to handle content negotiation, but we
need to put it in an internet draft so other people can comment on it
and implement it without having to refer to random email archives and
IRC logs.

a proposed solution

i propose we layer an abstract resource definition on top of the
abstract type system. the abstract resource definition can then be
used to describe a transfer syntax (aka serialization scheme) for
resources. we can then describe how each transport (HTTP(S), XMPP,
etc.) carries serialized resource data. we can then describe
interaction semantics independent of resource definition.

the benefit of this is it makes it easier to create systems that are
transport-neutral. some of the lessons we learned from Second Life=99
and the Linden Lab Legacy Protocol are that there's a LOT of stuff
that's not "real time" data. I suspect that moving forward, w= e'll
discover there are a lot of interactions that are modeled with the
request-response pattern. i am proposing a solution that would offer
deployers and protocol designers the ability to describe a resource
without describing the method in which it is accessed.

more details

this proposal describes five components: the abstract type system, the
abstract resource definition, the transfer syntax, the abstract
interaction definition and the transfer mapping.

abstract type system

as mentioned above, the abstract type system defines a core set of
types and type behavior. types are intended to be "concretized" i= n
programming languages like C, Java, Python, whatever. we create an
"abstract" type system so we're free to define the type behav= ior we
want while not being tied to type behavior of a particular
implementation language. individual implementers are responsible for
ensuring that type semantics are consistent with the spec.

for example, imagine you were developing an application using an
embedded 8 bit microprocessor and there was a protocol flow that
involved incrementing an integer. a client might send you a 32 bit
integer, assuming you would increment it. you would be responsible for
modeling the behavior of a 32 bit integer despite the fact your
micro-controller probably only natively knows about 16 bit ints.

abstract resource definition

the abstract resource definition is sort of like the abstract type
system for collections. we define a resource as being either an
individual item (a boolean, integer, etc.) or we define it as being a
map or an array. the abstract resource definition system allows
protocol developers to define the "shape" of resources. but becau= se
they are dynamic, implementations must allow for the type of a
resource to differ from it's definition and for elements in map to be added and removed.

for example, you may want to define the following resource to describe
an user logged into a system:

=A0RESOURCE agent {
=A0 name string,
=A0 identifier uri,
=A0 current_location uri
=A0}

the abstract resource definition is used to group named data elements
together into a dynamic structure. these structures will later be used
by the abstract interaction definition.

transfer syntax (aka serialization scheme)

these are basically the three serialization schemes defined in the
type-system draft: XML, JSON and Binary. they define how structured
data is serialized into an octet string in preparation for
transmission across a network. for example, the resource defined above
might be serialized like this:

<?xml version=3D"1.0" encoding=3D"UTF-8"?>
<!DOCTYPE map PUBLIC "+//IDN meadhbh.org//xxdsd 0.1//EN"
"http://home.meadhbh.org/xml/xxdsd/0.1/xxdsd.dtd">
<map>
=A0<key>name</key>
=A0<string>Meadhbh Oh</string>
=A0<key>identifier</key>
=A0<uri>http://world.secondlife.com/resi= dent/6e7477a7-2de5-4660-bc83-4a47096a18f0</uri>
=A0<key>current_location</key>
=A0<uri>http://world.secondlife.com/place/6= 5f385f0-691c-5755-9ef0-15f3bb05c8b7</uri>
</map>

abstract interaction definition

LLIDL currently defines access verb sets that are tied to HTTP verbs.
if we want to be able to access resources using multiple transports,
this is wrong. i propose we define an abstract interaction description
"language" that is later mapped to a particular transport.

i propose we have five "abstract" verbs: CREATE, READ, UPDATE, DE= LETE
and EVENT. the first four should be pretty straight forward. They're used to create resources, read and write them and then maybe delete
them. the last verb, EVENT, is used to define a resource an entity may
receive without requesting it. things like object updates, incoming
message session requests, etc.

transport mapping

the transport mapping maps abstract verbs from the abstract
interaction description language to concretized protocol flows in the
transport. so, for instance, you may use this to say that CREATE
abstract access methods map to a POST verb in HTTP or that an EVENT
message is delivered via the HTTP event queue.

conclusion

i'm going to wrap as much of this as i can into an internet draft and create some example code. but i figured i would get this idea out
there so people can comment on it. just lemme know what you think...

--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadh= bh.org/ * OhMeadhbh@gmail.com
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--0016367fbad4a8afb7048b7e63d9-- From ohmeadhbh@gmail.com Fri Jul 16 09:09:34 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63DAC3A67E7 for ; Fri, 16 Jul 2010 09:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 KhTKp1jRTRhI for ; Fri, 16 Jul 2010 09:09:33 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 215193A67B4 for ; Fri, 16 Jul 2010 09:09:33 -0700 (PDT) Received: by qwe5 with SMTP id 5so760079qwe.31 for ; Fri, 16 Jul 2010 09:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=ygc6iamnP3izpO9ONu3e20Tyo6W1xgSA1HBKXJXX0iA=; b=rSpCsxuV3r0qotMGdjeeHFhoB9gPmm2bIUHV71Fuud3VO43gb8Z4RbWlWxyjQVoWfk ARHuMcW3AsFx5SrfmPxi/errav01n0vVUmsk1PsmP6689UoetGkQyzwdcnG6rUUo8wKz MpWYUTsszqb0oTgZhQFHlsIEZq043r9TatJOY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=JLvix7ezHHHF0IrPp/jPVUb71FxMDQRfU79Iw54t1rhiXCqHQdTaoenuHMWniS2agX 4YEnNpnGorIKdbsH7b853a0UqHzRS3OyFpMsSDy1Zkv8xhzFjCFzIUrbW5RUJQlKq8Zy gK3zWB2r89w6pZob6hRC87svA5dAPYo+YPilQ= Received: by 10.224.110.206 with SMTP id o14mr1080942qap.69.1279296584402; Fri, 16 Jul 2010 09:09:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.13.225 with HTTP; Fri, 16 Jul 2010 09:09:24 -0700 (PDT) In-Reply-To: References: From: Meadhbh Hamrick Date: Fri, 16 Jul 2010 09:09:24 -0700 Message-ID: To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] thinking about LLIDL and the future X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 16:09:34 -0000 > EVENT is not a resource verb=A0 but an asynchronous transport > property of a resource, and if that property is enabled by a CRUD operati= on, > then EVENT messages are emitted under control of that resource. > hmmm.... okay... point taken. true enough, EVENT describes not a verb, but a message type. my motivation here is to identify unsolicited messages. i think it's unrealistic to assume that EVERY message will be properly modeled as a request / response. consider the situation when someone wants to open a chat session with you? is it better to model that interaction as an unsolicited message (like you receive an event saying: "hey. someone wants to open a chat session with you") or as a response to the request (like "this is my request that you alert me on my event queue when someone wants to chat with me.") so yeah, i agree that EVENT is not a verb in the way CRUD verbs are, but i don't agree that EVERY interaction in a virtual world is a synchronous request / response, which is why the EVENT was added. we could, however, say that the model implies a reverse client-server relationship over an event queue and in that case, things that were events would wind up being resources the server accesses using normal CRUD message types. it still doesn't help us if we want to model an object update with the abstract resource definition or interaction definition scheme. i think we're dealing not only with whether a message is synchronous, but also dealing with whether the message has been solicited. i think REQUIRING interactions to be both synchronous and solicited is a big mistake, cause it means we can't use the system to model object updates. -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com From morgaine.dinova@googlemail.com Fri Jul 16 11:04:39 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D7983A6AA2 for ; Fri, 16 Jul 2010 11:04:39 -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 TyvCnlVI5p04 for ; Fri, 16 Jul 2010 11:04:38 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id B3CFF3A659C for ; Fri, 16 Jul 2010 11:04:37 -0700 (PDT) Received: by wyb40 with SMTP id 40so2208243wyb.31 for ; Fri, 16 Jul 2010 11:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=8EpcwfEiLW415jYFeyWNrVDsRYVQUFD0mlmaFgoWpOA=; b=k1JPYV7yInMYkvNqkl/JcJFWSWJWPP0x/HnBEMtdZvvf10IhfPrf6C85djTSHLEp6N 4I/lf4dWFiwN3vzr8oE/6I+FIZInB0LFwHJ06sVGH6GQAuJRCXiUIj+YMkqMdkCqA4VV CMzLTTBlpbayjgBXdaMUD0PikQebhWJLMtwuw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=GlOmGNLpsCU1ZfBl5Ix9uQ4Lw4CO13m2liilL4Bjw59T5/eIqH4cwG1H9D7IEjn2cc ar71uwOvwzFuxi+VTzAH4oiD3r0cDme+KmxpMRtV3LQuabCNs2jLekKA2ZftMgdh2p9l nAg3wh6gokEhjzerQlCl2TjrCFz482vaNfRZs= MIME-Version: 1.0 Received: by 10.216.52.197 with SMTP id e47mr1043670wec.99.1279303484707; Fri, 16 Jul 2010 11:04:44 -0700 (PDT) Received: by 10.216.139.215 with HTTP; Fri, 16 Jul 2010 11:04:44 -0700 (PDT) In-Reply-To: References: Date: Fri, 16 Jul 2010 19:04:44 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016e6dee6dec412e1048b850d9a Subject: Re: [vwrap] thinking about LLIDL and the future X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 18:04:39 -0000 --0016e6dee6dec412e1048b850d9a Content-Type: text/plain; charset=ISO-8859-1 Considering asynchronous messages to be emitted in response to a CRUD operation on an appropriate resource fits in perfectly with the notion of Capabilities though. They ARE solicited, by a request to a resource. As in my earlier example of the text-only client, the CRUD operation UPDATE(scenegraph_updates_capability, ENABLE) was not invoked by the client (or it was invoked with the argument DISABLE), and hence that resource saves time and bandwidth by not sending the unwanted scenegraph updates. If instead the resource were set to ENABLE, those update messages would certainly be appearing in response to the ENABLE request, so it's a natural interpretation. And of course it's very helpful to have such events controlled by a capability. The alternative model in which events are considered normal CRUD operations on an event queue in the reverse direction is actually incorrect, because then those operations would require responses themselves, and that's not what we want. Events don't fit the synchronous request-response model, because they're not synchronous, and are ill-suited to a 2-way request-response paradigm for every event message. That's why I prefer the unidirectional model in which events occur as a sequence of zero or more messages in response to a normal CRUD operation. It's a clean model because the responses travel in the reverse direction perfectly naturally (since they're responses) and do not themselves require further ACKs. It's also justified because, after all, we will require a means of enabling / disabling updates and other asynchronous event notifications. This model kills two birds with one stone, and it's a natural fit for capabilities. Morgaine. ================================== On Fri, Jul 16, 2010 at 5:09 PM, Meadhbh Hamrick wrote: > > EVENT is not a resource verb but an asynchronous transport > > property of a resource, and if that property is enabled by a CRUD > operation, > > then EVENT messages are emitted under control of that resource. > > > > hmmm.... okay... point taken. true enough, EVENT describes not a verb, > but a message type. > > my motivation here is to identify unsolicited messages. i think it's > unrealistic to assume that EVERY message will be properly modeled as a > request / response. consider the situation when someone wants to open > a chat session with you? is it better to model that interaction as an > unsolicited message (like you receive an event saying: "hey. someone > wants to open a chat session with you") or as a response to the > request (like "this is my request that you alert me on my event queue > when someone wants to chat with me.") > > so yeah, i agree that EVENT is not a verb in the way CRUD verbs are, > but i don't agree that EVERY interaction in a virtual world is a > synchronous request / response, which is why the EVENT was added. > > we could, however, say that the model implies a reverse client-server > relationship over an event queue and in that case, things that were > events would wind up being resources the server accesses using normal > CRUD message types. > > it still doesn't help us if we want to model an object update with the > abstract resource definition or interaction definition scheme. > > i think we're dealing not only with whether a message is synchronous, > but also dealing with whether the message has been solicited. i think > REQUIRING interactions to be both synchronous and solicited is a big > mistake, cause it means we can't use the system to model object > updates. > > -cheers > -meadhbh > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > --0016e6dee6dec412e1048b850d9a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Considering asynchronous messages to be emitted in response to a CRUD opera= tion on an appropriate resource fits in perfectly with the notion of Capabi= lities though.=A0 They ARE solicited, by a request to a resource.

As= in my earlier example of the text-only client, the CRUD operation UPDATE(s= cenegraph_updates_capability, ENABLE) was not invoked by the client (or it = was invoked with the argument DISABLE), and hence that resource saves time = and bandwidth by not sending the unwanted scenegraph updates.=A0 If instead= the resource were set to ENABLE, those update messages would certainly be = appearing in response to the ENABLE request, so it's a natural interpre= tation.=A0 And of course it's very helpful to have such events controll= ed by a capability.

The alternative model in which events are considered normal CRUD operat= ions on an event queue in the reverse direction is actually incorrect, beca= use then those operations would require responses themselves, and that'= s not what we want.=A0 Events don't fit the synchronous request-respons= e model, because they're not synchronous, and are ill-suited to a 2-way= request-response paradigm for every event message.

That's why I prefer the unidirectional model in which events occur = as a sequence of zero or more messages in response to a normal CRUD operati= on.=A0 It's a clean model because the responses travel in the reverse d= irection perfectly naturally (since they're responses) and do not thems= elves require further ACKs.=A0 It's also justified because, after all, = we will require a means of enabling / disabling updates and other asynchron= ous event notifications.=A0 This model kills two birds with one stone, and = it's a natural fit for capabilities.


Morgaine.




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

<= div class=3D"gmail_quote">On Fri, Jul 16, 2010 at 5:09 PM, Meadhbh Hamrick = <ohmeadhbh@gmai= l.com> wrote:
> EVENT is not a resource verb=A0 but an asynchronous transport
> property of a resource, and if that property is enabled by a CRUD oper= ation,
> then EVENT messages are emitted under control of that resource.
>

hmmm.... okay... point taken. true enough, EVENT describes not a verb= ,
but a message type.

my motivation here is to identify unsolicited messages. i think it's unrealistic to assume that EVERY message will be properly modeled as a
request / response. consider the situation when someone wants to open
a chat session with you? is it better to model that interaction as an
unsolicited message (like you receive an event saying: "hey. someone wants to open a chat session with you") or as a response to the
request (like "this is my request that you alert me on my event queue<= br> when someone wants to chat with me.")

so yeah, i agree that EVENT is not a verb in the way CRUD verbs are,
but i don't agree that EVERY interaction in a virtual world is a
synchronous request / response, which is why the EVENT was added.

we could, however, say that the model implies a reverse client-server
relationship over an event queue and in that case, things that were
events would wind up being resources the server accesses using normal
CRUD message types.

it still doesn't help us if we want to model an object update with the<= br> abstract resource definition or interaction definition scheme.

i think we're dealing not only with whether a message is synchronous, but also dealing with whether the message has been solicited. i think
REQUIRING interactions to be both synchronous and solicited is a big
mistake, cause it means we can't use the system to model object
updates.

-cheers
-meadhbh
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadh= bh.org/ * OhMeadhbh@gmail.com

--0016e6dee6dec412e1048b850d9a-- From dzonatas@gmail.com Fri Jul 16 11:08:40 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD9AC3A6AC7 for ; Fri, 16 Jul 2010 11:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ihrPYbTmPRd for ; Fri, 16 Jul 2010 11:08:39 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id D38C23A6A61 for ; Fri, 16 Jul 2010 11:08:39 -0700 (PDT) Received: by pxi20 with SMTP id 20so1398835pxi.31 for ; Fri, 16 Jul 2010 11:08:51 -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=M1hrAS5Uj7U4XXtqtxXr3eaSfbc0JZ212dt7IQ05itA=; b=OZ6HLD+5+JW17G9dEkcafJWLfBDmFDQu3C5Gl1MiU4KVaAMM2YX+FESdHSmHJq3pdh 6OmJWwlWuITTkE2gDFktI4wo8yAiZe/RbscbNPZtxT+oZuJXAUAvfft4Q3LpoHra8DAN /PDvxRAYoOjIjtj4X5hcH1TmZJghrWqbgv+sQ= 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=TEd3h8w/sST9OC6AB6ClpgmU2k6/MBwADW9oMjOdhg50cewEMQsha9Ke/l58btW9uN 3srQL0xunSnpu66Sk47n3Z4Qew7QbpLkbWOSzl4If0muxyTV9F4ZoE/JV5GrcWNnDiMU 6z95Uu4ANHMFHFY9C37blbDN/BIfvNEFVW9k4= Received: by 10.114.15.2 with SMTP id 2mr2087559wao.67.1279303731700; Fri, 16 Jul 2010 11:08:51 -0700 (PDT) Received: from [192.168.0.50] (adsl-69-105-197-115.dsl.scrm01.pacbell.net [69.105.197.115]) by mx.google.com with ESMTPS id q6sm25584483waj.22.2010.07.16.11.08.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 16 Jul 2010 11:08:50 -0700 (PDT) Message-ID: <4C40A30F.30404@gmail.com> Date: Fri, 16 Jul 2010 11:21:03 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Meadhbh Hamrick References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: vwrap@ietf.org Subject: Re: [vwrap] thinking about LLIDL and the future X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 18:08:41 -0000 Meadhbh Hamrick wrote: > my motivation here is to identify unsolicited messages. Good idea since that is the basic message until they are identified as solicited. One step away from the transport protocol, there are three main flows noticed in ReST design: simple queries, complex queries, and task(lets). Of those three, I said flow because of the direction of data expected: unidirectional, bidirection, and only internal. The GET method is comparable to a simple query. The POST method is comparable to a complex query, especially if it expect further processing after HTTP_OK|HTTP_ACCEPTED status. Tasks are pretty much the core type that are abstracted into these other types described above and in related thread. Yes, being able to describe or abstract from these basics I think is more desirable than than worry about PUT, DELETE, etc. Those extra details that are complex and don't let us easily bridge the digital gap, one needed to cross in order to explain to users how to basically extend VWRAP. From ohmeadhbh@gmail.com Fri Jul 16 11:45:08 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 558793A689E for ; Fri, 16 Jul 2010 11:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.260, 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 SL0oRsXHx7-n for ; Fri, 16 Jul 2010 11:45:07 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id B56A83A6870 for ; Fri, 16 Jul 2010 11:45:06 -0700 (PDT) Received: by vws14 with SMTP id 14so3015619vws.31 for ; Fri, 16 Jul 2010 11:45:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:received :in-reply-to:references:date:message-id:subject:from:to:cc :content-type; bh=kx2wKl7wNDla2ZsZWtZm4nwXjTK6P24WGL1IA2UA0nw=; b=upKphowR7gJEFkHpj99ne1l2MDslSfIX27+C1aXm6u0ogxYx8gZl5EW7Vjm6PWqJjv rSlvrK4iwPiZjbQuiJt9PPGrSfwdo7BCuXU6nyTYUJVvfRhewRbHrJb4Sjn0cz1JnFMh WgOxyMQBEMtr9+rWjMcND5zwy0O/Pq/7K4g4A= 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=fAnYeqGEY2sAmka7Hc8XpDPCs4YV2j7gncheu/AJjqh5fvKiuVHl+g44IN8UsfkaeU /AzfgIHxonnigt4w/N5/dpK2ADka9/7NroIH2goUKTyIt+hCvCXAjpM+/TE74ay6p1Fr 3zsFm2JoQtITiz2L+lbzZx3P3qMRhqBljwxoQ= MIME-Version: 1.0 Received: by 10.220.59.202 with SMTP id m10mr774698vch.188.1279305918229; Fri, 16 Jul 2010 11:45:18 -0700 (PDT) Received: by 10.229.13.225 with HTTP; Fri, 16 Jul 2010 11:45:18 -0700 (PDT) Received: by 10.229.13.225 with HTTP; Fri, 16 Jul 2010 11:45:18 -0700 (PDT) In-Reply-To: References: Date: Fri, 16 Jul 2010 11:45:18 -0700 Message-ID: From: Meadhbh Hamrick To: Morgaine Content-Type: multipart/alternative; boundary=e0cb4e887827d0ad2f048b859e23 Cc: vwrap@ietf.org Subject: Re: [vwrap] thinking about LLIDL and the future X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 18:45:08 -0000 --e0cb4e887827d0ad2f048b859e23 Content-Type: text/plain; charset=ISO-8859-1 Interesting. I had been thinking that the message semantics would require a response on the same channel as the request. What you're talking about seems to be a little higher level than what I'm pitching. (Thx for pointing out I wasn't clear about this) So.. the way I'm modeling it is that you have message interactions that are tied to the same transport session. So if you ask for something with http(s), you get it back via http(s) on the same connection. But it's definitely true that an application layer entity can coordinate messages, only I think we should make a "virtual" connection that spans actual connections. But I still think it's advantageous to think of interaction patterns in terms of message flows over specific connections, otherwise we have to start adding application layer transaction id's to correlate responses to requests. Also, since trust seems to be associated with connections (by way of (D)TLS), it's probably a good idea to not cross trust boundaries in interactions across connections, otherwise we would have to model that in the application layer as well. At the end of the day, we have message patterns that look like: * send, no reply expected * request, response expected and * unsolicited message. The first two can be modeled with request/response, but the last one has unique characteristics that must be modeled. -cheers -meadhbh On Jul 16, 2010 11:05 AM, "Morgaine" wrote: Considering asynchronous messages to be emitted in response to a CRUD operation on an appropriate resource fits in perfectly with the notion of Capabilities though. They ARE solicited, by a request to a resource. As in my earlier example of the text-only client, the CRUD operation UPDATE(scenegraph_updates_capability, ENABLE) was not invoked by the client (or it was invoked with the argument DISABLE), and hence that resource saves time and bandwidth by not sending the unwanted scenegraph updates. If instead the resource were set to ENABLE, those update messages would certainly be appearing in response to the ENABLE request, so it's a natural interpretation. And of course it's very helpful to have such events controlled by a capability. The alternative model in which events are considered normal CRUD operations on an event queue in the reverse direction is actually incorrect, because then those operations would require responses themselves, and that's not what we want. Events don't fit the synchronous request-response model, because they're not synchronous, and are ill-suited to a 2-way request-response paradigm for every event message. That's why I prefer the unidirectional model in which events occur as a sequence of zero or more messages in response to a normal CRUD operation. It's a clean model because the responses travel in the reverse direction perfectly naturally (since they're responses) and do not themselves require further ACKs. It's also justified because, after all, we will require a means of enabling / disabling updates and other asynchronous event notifications. This model kills two birds with one stone, and it's a natural fit for capabilities. Morgaine. ================================== On Fri, Jul 16, 2010 at 5:09 PM, Meadhbh Hamrick wrote: > > > EVENT is not a... _______________________________________________ vwrap mailing list vwrap@ietf.org https://www.ietf.org/mailman/listinfo/vwrap --e0cb4e887827d0ad2f048b859e23 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Interesting. I had been thinking that the message semantics would requir= e a response on the same channel as the request. What you're talking ab= out seems to be a little higher level than what I'm pitching. (Thx for = pointing out I wasn't clear about this)

So.. the way I'm modeling it is that you have message interactions t= hat are tied to the same transport session. So if you ask for something wit= h http(s), you get it back via http(s) on the same connection.

But it's definitely true that an application layer entity can coordi= nate messages, only I think we should make a "virtual" connection= that spans actual connections.

But I still think it's advantageous to think of interaction patterns= in terms of message flows over specific connections, otherwise we have to = start adding application layer transaction id's to correlate responses = to requests. Also, since trust seems to be associated with connections (by = way of (D)TLS), it's probably a good idea to not cross trust boundaries= in interactions across connections, otherwise we would have to model that = in the application layer as well.

At the end of the day, we have message patterns that look like:

* send, no reply expected
* request, response expected
and
* unsolicited message.

The first two can be modeled with request/response, but the last one has= unique characteristics that must be modeled.

-cheers
-meadhbh

On Jul 16, 2010 11:05 AM, "Morgaine"= <mo= rgaine.dinova@googlemail.com> wrote:

Considering asynchronous= messages to be emitted in response to a CRUD operation on an appropriate r= esource fits in perfectly with the notion of Capabilities though.=A0 They A= RE solicited, by a request to a resource.

As in my earlier example of the text-only client, the CRUD operation UP= DATE(scenegraph_updates_capability, ENABLE) was not invoked by the client (= or it was invoked with the argument DISABLE), and hence that resource saves= time and bandwidth by not sending the unwanted scenegraph updates.=A0 If i= nstead the resource were set to ENABLE, those update messages would certain= ly be appearing in response to the ENABLE request, so it's a natural in= terpretation.=A0 And of course it's very helpful to have such events co= ntrolled by a capability.

The alternative model in which events are considered normal CRUD operat= ions on an event queue in the reverse direction is actually incorrect, beca= use then those operations would require responses themselves, and that'= s not what we want.=A0 Events don't fit the synchronous request-respons= e model, because they're not synchronous, and are ill-suited to a 2-way= request-response paradigm for every event message.

That's why I prefer the unidirectional model in which events occur = as a sequence of zero or more messages in response to a normal CRUD operati= on.=A0 It's a clean model because the responses travel in the reverse d= irection perfectly naturally (since they're responses) and do not thems= elves require further ACKs.=A0 It's also justified because, after all, = we will require a means of enabling / disabling updates and other asynchron= ous event notifications.=A0 This model kills two birds with one stone, and = it's a natural fit for capabilities.


Morgaine.




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

On Fri, Jul 16, 2010 at 5:09 PM, Meadhbh H= amrick <ohmeadh= bh@gmail.com> wrote:
>
> > EVENT is not a...


_________________________= ______________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--e0cb4e887827d0ad2f048b859e23-- From morgaine.dinova@googlemail.com Fri Jul 16 22:42:45 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20F413A6784 for ; Fri, 16 Jul 2010 22:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_24=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 nL-iDlj-8Js3 for ; Fri, 16 Jul 2010 22:42:41 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 3EE7E3A6359 for ; Fri, 16 Jul 2010 22:42:41 -0700 (PDT) Received: by wyb40 with SMTP id 40so2769011wyb.31 for ; Fri, 16 Jul 2010 22:41:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=6T/IElHlJ2/4FUI42/Sr6VkU6Gq1d8NRYmJSQNWsW6g=; b=BEry61nv83YDXL7rhzB0cqnQQZuTElE9VVXQV3qlI/bsI25aAXVCmM6IBdyBOkvJ4O Mbrj7q3IFUkBIqsCPD5dVS2O5Lpjl7FCgsglLSQ/Bji9DqgvaYw5IELmonG+KaSByYYU iI60kfkL9ARzw2mpRj41W04yxCjkifgBZI/dc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=fHUJHQuoIOGYWp0haCWJP7abjunTaRdc67o1J478InN0HKSdK3hWnokeZBH4Qovuyl FmCLxsz1pyyNcEX6eFfInR4+xtEoCMaeGWhwHAMlKx6BqCxhkP7ogDoZSplcNf17yNdH 5Vau7WxFsg4BgMV/9BGh3QdiSu2xEB4hxs/mM= MIME-Version: 1.0 Received: by 10.216.170.200 with SMTP id p50mr1459236wel.96.1279345269378; Fri, 16 Jul 2010 22:41:09 -0700 (PDT) Received: by 10.216.139.215 with HTTP; Fri, 16 Jul 2010 22:41:09 -0700 (PDT) In-Reply-To: References: Date: Sat, 17 Jul 2010 06:41:09 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016367b60a65393ff048b8ec835 Subject: Re: [vwrap] thinking about LLIDL and the future X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2010 05:42:45 -0000 --0016367b60a65393ff048b8ec835 Content-Type: text/plain; charset=ISO-8859-1 That's correct, I was describing flows at the capability level, not at the transport level. The transport is exactly as you deduced, namely with separate transports for capability request-response and for asynchronous event messaging. When you send an ENABLE to the capability that controls a particular asynchronous event stream, you receive back the normal capability OK response on the same channel as the request (as expected), but the event messaging that this enables occurs on a distinct channel at the transport level. This makes a lot of sense for practical implementations, because event messaging requires high bandwidth and low latency and so it is best handled on a separate transport and using the most efficient form of serialization. As an implementation example, the OK response from the request to the capability could return the IP address and port of the event messaging source host, the client would open a TCP stream to it, the source host would send events asynchronously down the pipe, and the client's event listener would dispatch the event frames to appropriate event handlers as the messages arrive. Different event-generating capabilities could choose to return different IP:port pairs to harness dynamic load-balanced server pools and to provide parallel pathing, or they could choose to share a common event transport --- these would be simple site configuration choices. Note that this is highly scalable, since it allows any number of servers to participate in event generation and distribution. No longer do updates have to come from a single, horribly overloaded and totally non-scalable simulator host. Consistent with David's regular exhortations, nothing in the above precludes this model from working in the legacy deployment architectures of SL and Opensim: single simulator operation is still supported by the design, but it offers additional capability for more scalable deployments. Morgaine. ===================================== On Fri, Jul 16, 2010 at 7:45 PM, Meadhbh Hamrick wrote: > Interesting. I had been thinking that the message semantics would require a > response on the same channel as the request. What you're talking about seems > to be a little higher level than what I'm pitching. (Thx for pointing out I > wasn't clear about this) > > So.. the way I'm modeling it is that you have message interactions that are > tied to the same transport session. So if you ask for something with > http(s), you get it back via http(s) on the same connection. > > But it's definitely true that an application layer entity can coordinate > messages, only I think we should make a "virtual" connection that spans > actual connections. > > But I still think it's advantageous to think of interaction patterns in > terms of message flows over specific connections, otherwise we have to start > adding application layer transaction id's to correlate responses to > requests. Also, since trust seems to be associated with connections (by way > of (D)TLS), it's probably a good idea to not cross trust boundaries in > interactions across connections, otherwise we would have to model that in > the application layer as well. > > At the end of the day, we have message patterns that look like: > > * send, no reply expected > * request, response expected > and > * unsolicited message. > > The first two can be modeled with request/response, but the last one has > unique characteristics that must be modeled. > > -cheers > -meadhbh > > On Jul 16, 2010 11:05 AM, "Morgaine" > wrote: > > Considering asynchronous messages to be emitted in response to a CRUD > operation on an appropriate resource fits in perfectly with the notion of > Capabilities though. They ARE solicited, by a request to a resource. > > As in my earlier example of the text-only client, the CRUD operation > UPDATE(scenegraph_updates_capability, ENABLE) was not invoked by the client > (or it was invoked with the argument DISABLE), and hence that resource saves > time and bandwidth by not sending the unwanted scenegraph updates. If > instead the resource were set to ENABLE, those update messages would > certainly be appearing in response to the ENABLE request, so it's a natural > interpretation. And of course it's very helpful to have such events > controlled by a capability. > > The alternative model in which events are considered normal CRUD operations > on an event queue in the reverse direction is actually incorrect, because > then those operations would require responses themselves, and that's not > what we want. Events don't fit the synchronous request-response model, > because they're not synchronous, and are ill-suited to a 2-way > request-response paradigm for every event message. > > That's why I prefer the unidirectional model in which events occur as a > sequence of zero or more messages in response to a normal CRUD operation. > It's a clean model because the responses travel in the reverse direction > perfectly naturally (since they're responses) and do not themselves require > further ACKs. It's also justified because, after all, we will require a > means of enabling / disabling updates and other asynchronous event > notifications. This model kills two birds with one stone, and it's a > natural fit for capabilities. > > > Morgaine. > > > > > ================================== > > > > On Fri, Jul 16, 2010 at 5:09 PM, Meadhbh Hamrick > wrote: > > > > > EVENT is not a... > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > --0016367b60a65393ff048b8ec835 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That's correct, I was describing flows at the capability level, not at = the transport level.=A0 The transport is exactly as you deduced, namely wit= h separate transports for capability request-response and for asynchronous = event messaging.

When you send an ENABLE to the capability that controls a particular as= ynchronous event stream, you receive back the normal capability OK response= on the same channel as the request (as expected), but the event messaging = that this enables occurs on a distinct channel at the transport level.

This makes a lot of sense for practical implementations, because event = messaging requires high bandwidth and low latency and so it is best handled= on a separate transport and using the most efficient form of serialization= .

As an implementation example, the OK response from the request to the c= apability could return the IP address and port of the event messaging sourc= e host, the client would open a TCP stream to it, the source host would sen= d events asynchronously down the pipe, and the client's event listener = would dispatch the event frames to appropriate event handlers as the messag= es arrive.

Different event-generating capabilities could choose to return differen= t IP:port pairs to harness dynamic load-balanced server pools and to provid= e parallel pathing, or they could choose to share a common event transport = --- these would be simple site configuration choices.

Note that this is highly scalable, since it allows any number of server= s to participate in event generation and distribution.=A0 No longer do upda= tes have to come from a single, horribly overloaded and totally non-scalabl= e simulator host.

Consistent with David's regular exhortations, nothing in the above = precludes this model from working in the legacy deployment architectures of= SL and Opensim:=A0 single simulator operation is still supported by the de= sign, but it offers additional capability for more scalable deployments.

Morgaine.





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

On Fri, Jul 16, 2010 at 7:45 PM, Mead= hbh Hamrick <oh= meadhbh@gmail.com> wrote:

Interesting. I= had been thinking that the message semantics would require a response on t= he same channel as the request. What you're talking about seems to be a= little higher level than what I'm pitching. (Thx for pointing out I wa= sn't clear about this)

So.. the way I'm modeling it is that you have message interactions t= hat are tied to the same transport session. So if you ask for something wit= h http(s), you get it back via http(s) on the same connection.

But it's definitely true that an application layer entity can coordi= nate messages, only I think we should make a "virtual" connection= that spans actual connections.

But I still think it's advantageous to think of interaction patterns= in terms of message flows over specific connections, otherwise we have to = start adding application layer transaction id's to correlate responses = to requests. Also, since trust seems to be associated with connections (by = way of (D)TLS), it's probably a good idea to not cross trust boundaries= in interactions across connections, otherwise we would have to model that = in the application layer as well.

At the end of the day, we have message patterns that look like:

* send, no reply expected
* request, response expected
and
* unsolicited message.

The first two can be modeled with request/response, but the last one has= unique characteristics that must be modeled.

-cheers
-meadhbh

On Jul 16, 2010 11:05 AM= , "Morgaine" <morgaine.dinova@googlemail.com> wrote:

Co= nsidering asynchronous messages to be emitted in response to a CRUD operati= on on an appropriate resource fits in perfectly with the notion of Capabili= ties though.=A0 They ARE solicited, by a request to a resource.

As in my earlier example of the text-only client, the CRUD operation UP= DATE(scenegraph_updates_capability, ENABLE) was not invoked by the client (= or it was invoked with the argument DISABLE), and hence that resource saves= time and bandwidth by not sending the unwanted scenegraph updates.=A0 If i= nstead the resource were set to ENABLE, those update messages would certain= ly be appearing in response to the ENABLE request, so it's a natural in= terpretation.=A0 And of course it's very helpful to have such events co= ntrolled by a capability.

The alternative model in which events are considered normal CRUD operat= ions on an event queue in the reverse direction is actually incorrect, beca= use then those operations would require responses themselves, and that'= s not what we want.=A0 Events don't fit the synchronous request-respons= e model, because they're not synchronous, and are ill-suited to a 2-way= request-response paradigm for every event message.

That's why I prefer the unidirectional model in which events occur = as a sequence of zero or more messages in response to a normal CRUD operati= on.=A0 It's a clean model because the responses travel in the reverse d= irection perfectly naturally (since they're responses) and do not thems= elves require further ACKs.=A0 It's also justified because, after all, = we will require a means of enabling / disabling updates and other asynchron= ous event notifications.=A0 This model kills two birds with one stone, and = it's a natural fit for capabilities.


Morgaine.




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



On Fri, Jul 16, 20= 10 at 5:09 PM, Meadhbh Hamrick <ohmeadhbh@gmail.com> wrote:
>
> > EVENT is not a...


_= ______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap


--0016367b60a65393ff048b8ec835-- From ohmeadhbh@gmail.com Fri Jul 16 23:27:23 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F1693A688A for ; Fri, 16 Jul 2010 23:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.082 X-Spam-Level: X-Spam-Status: No, score=-2.082 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, J_CHICKENPOX_24=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 FyTDLGRBGsPi for ; Fri, 16 Jul 2010 23:27:21 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 6D0343A687F for ; Fri, 16 Jul 2010 23:27:21 -0700 (PDT) Received: by qwe5 with SMTP id 5so1023719qwe.31 for ; Fri, 16 Jul 2010 23:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=uH+Td5wxOoJ7B/kEkzquL0kGmMK1xT7gcg6UiDEe98A=; b=QkDHsVW/CQuylsMU6dcQrySxj2gl4kOvV2tbB/hf2bpFDtEr8Bcsgq4c9hm3hWFNui qrnqVExNkdABGhsKNQ+oqyJpiXjvBntpiEWy+mS3sjr9aRv+VRGWMM5wxOPsdfFmql+a dH1CTAn2PyLqLEuo86qx9aKJ0dSaHAkpGzems= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=WfVstYxZVAz0XhNmD8151Yp7RZ0VKP977HsFDU2jJSBWjHYptePtMJc5+w2Oidm797 tdV+vJVJf/9X6glHMhuwkQMA8Zy3cfRjKPObcXU8Bjn8dxTxrdshtudHDDM+0SoXmDke xI+QFC+TS9GGMReHYBhuiUaKJNeEZYP4AE5m4= Received: by 10.224.106.149 with SMTP id x21mr1735482qao.16.1279348053222; Fri, 16 Jul 2010 23:27:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.13.225 with HTTP; Fri, 16 Jul 2010 23:27:12 -0700 (PDT) In-Reply-To: References: From: Meadhbh Hamrick Date: Fri, 16 Jul 2010 23:27:12 -0700 Message-ID: To: Morgaine , Dzonatas Sol Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] thinking about LLIDL and the future X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2010 06:27:23 -0000 okay. i think i understand you and dzonatas well enough to go out and write another, completely unofficial, possibly experimental draft for the group. then maybe a little bit of PHP and JavaScript to demonstrate a few of the features. again, thanks for the comments (and this is by no means the end of the commentary on my extended type system.) i think it's just easier for me to have a conversation about it after having real documents and a sample implementation to look at. i'm going to probably drop out of the conversation for a week as i go off and work on this stuff. i'll keep a lookout for additional comments, and try to address them in my next draft. but i probably won't have bandwidth to discuss them for a week or so. -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Fri, Jul 16, 2010 at 10:41 PM, Morgaine wrote: > That's correct, I was describing flows at the capability level, not at th= e > transport level.=A0 The transport is exactly as you deduced, namely with > separate transports for capability request-response and for asynchronous > event messaging. > > When you send an ENABLE to the capability that controls a particular > asynchronous event stream, you receive back the normal capability OK > response on the same channel as the request (as expected), but the event > messaging that this enables occurs on a distinct channel at the transport > level. > > This makes a lot of sense for practical implementations, because event > messaging requires high bandwidth and low latency and so it is best handl= ed > on a separate transport and using the most efficient form of serializatio= n. > > As an implementation example, the OK response from the request to the > capability could return the IP address and port of the event messaging > source host, the client would open a TCP stream to it, the source host wo= uld > send events asynchronously down the pipe, and the client's event listener > would dispatch the event frames to appropriate event handlers as the > messages arrive. > > Different event-generating capabilities could choose to return different > IP:port pairs to harness dynamic load-balanced server pools and to provid= e > parallel pathing, or they could choose to share a common event transport = --- > these would be simple site configuration choices. > > Note that this is highly scalable, since it allows any number of servers = to > participate in event generation and distribution.=A0 No longer do updates= have > to come from a single, horribly overloaded and totally non-scalable > simulator host. > > Consistent with David's regular exhortations, nothing in the above preclu= des > this model from working in the legacy deployment architectures of SL and > Opensim:=A0 single simulator operation is still supported by the design, = but > it offers additional capability for more scalable deployments. > > > Morgaine. > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > On Fri, Jul 16, 2010 at 7:45 PM, Meadhbh Hamrick > wrote: >> >> Interesting. I had been thinking that the message semantics would requir= e >> a response on the same channel as the request. What you're talking about >> seems to be a little higher level than what I'm pitching. (Thx for point= ing >> out I wasn't clear about this) >> >> So.. the way I'm modeling it is that you have message interactions that >> are tied to the same transport session. So if you ask for something with >> http(s), you get it back via http(s) on the same connection. >> >> But it's definitely true that an application layer entity can coordinate >> messages, only I think we should make a "virtual" connection that spans >> actual connections. >> >> But I still think it's advantageous to think of interaction patterns in >> terms of message flows over specific connections, otherwise we have to s= tart >> adding application layer transaction id's to correlate responses to >> requests. Also, since trust seems to be associated with connections (by = way >> of (D)TLS), it's probably a good idea to not cross trust boundaries in >> interactions across connections, otherwise we would have to model that i= n >> the application layer as well. >> >> At the end of the day, we have message patterns that look like: >> >> * send, no reply expected >> * request, response expected >> and >> * unsolicited message. >> >> The first two can be modeled with request/response, but the last one has >> unique characteristics that must be modeled. >> >> -cheers >> -meadhbh >> >> On Jul 16, 2010 11:05 AM, "Morgaine" >> wrote: >> >> Considering asynchronous messages to be emitted in response to a CRUD >> operation on an appropriate resource fits in perfectly with the notion o= f >> Capabilities though.=A0 They ARE solicited, by a request to a resource. >> >> As in my earlier example of the text-only client, the CRUD operation >> UPDATE(scenegraph_updates_capability, ENABLE) was not invoked by the cli= ent >> (or it was invoked with the argument DISABLE), and hence that resource s= aves >> time and bandwidth by not sending the unwanted scenegraph updates.=A0 If >> instead the resource were set to ENABLE, those update messages would >> certainly be appearing in response to the ENABLE request, so it's a natu= ral >> interpretation.=A0 And of course it's very helpful to have such events >> controlled by a capability. >> >> The alternative model in which events are considered normal CRUD >> operations on an event queue in the reverse direction is actually incorr= ect, >> because then those operations would require responses themselves, and th= at's >> not what we want.=A0 Events don't fit the synchronous request-response m= odel, >> because they're not synchronous, and are ill-suited to a 2-way >> request-response paradigm for every event message. >> >> That's why I prefer the unidirectional model in which events occur as a >> sequence of zero or more messages in response to a normal CRUD operation= . >> It's a clean model because the responses travel in the reverse direction >> perfectly naturally (since they're responses) and do not themselves requ= ire >> further ACKs.=A0 It's also justified because, after all, we will require= a >> means of enabling / disabling updates and other asynchronous event >> notifications.=A0 This model kills two birds with one stone, and it's a >> natural fit for capabilities. >> >> >> Morgaine. >> >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> On Fri, Jul 16, 2010 at 5:09 PM, Meadhbh Hamrick >> wrote: >> > >> > > EVENT is not a... >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > From morgaine.dinova@googlemail.com Sat Jul 17 00:34:45 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0BCE3A67A4 for ; Sat, 17 Jul 2010 00:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.526 X-Spam-Level: X-Spam-Status: No, score=-1.526 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_24=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 65fRc4uOae0a for ; Sat, 17 Jul 2010 00:34:43 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id F3AAB3A6359 for ; Sat, 17 Jul 2010 00:34:42 -0700 (PDT) Received: by wyb40 with SMTP id 40so2826648wyb.31 for ; Sat, 17 Jul 2010 00:34:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=k/p/kPiRSVLPTVlfNapFjA24sWysSAMXLC8qiPORH5M=; b=MtW69a6u76gy7EytaQQRTZBZ5eek2XBA4CaqgkitAfKghOy7zbZqSN7Wmz9VTnODvI FXMOKYQkWfenSpXhzBeSugPsXNnVYoaAhfnbR50RDeM0iDFIRNM81nJJX2WMcQ3UP2UV WK2GKEMgZ7rM1yRvIgUWYG8HBDT9yGm06nqpE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=jhGNcl58+HknoaZDRlCCoZYiUSfxn+p3Dn/+iAygrQkHDUhAGl2iPnq38qL85zOovz UDupmVrttSh7QB6EWtaIkh2jL0dO9yk1OqFQdTIOx9bPWnWGdhmKOwFLcVeXmuOS8xzJ FNS0+fbRg5PJd/DF6PqQAKzczj5B+8jWkEPwM= MIME-Version: 1.0 Received: by 10.216.170.200 with SMTP id p50mr1522334wel.96.1279352091647; Sat, 17 Jul 2010 00:34:51 -0700 (PDT) Received: by 10.216.139.215 with HTTP; Sat, 17 Jul 2010 00:34:51 -0700 (PDT) In-Reply-To: References: Date: Sat, 17 Jul 2010 08:34:51 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016367b60a6f7245b048b905ea2 Subject: Re: [vwrap] thinking about LLIDL and the future X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2010 07:34:45 -0000 --0016367b60a6f7245b048b905ea2 Content-Type: text/plain; charset=ISO-8859-1 Righto Meadhbh, I'm looking forward to that. It's worth noting that this design pattern works for many services and subsystems in our kind of VW architecture. Wherever a capability enables a service that operates over a separate transport, the capability grant can supply dynamic IP:port pairs for the transport and hence quite trivially harness load balancing for the service in question. We can certainly apply this not only to object updates but also to group IM, world notifications, and to search. Any region-specific assets such as terrain also fit the model well for load-balanced streaming, and even baked avatars served from load-balanced pools fit the model. It's a generic design that is much more flexible and controllable than access dispersal to dynamic pools through DNS or through load balancers, and it provides good security as well, and no single point of failure. Morgaine. ================================ On Sat, Jul 17, 2010 at 7:27 AM, Meadhbh Hamrick wrote: > okay. i think i understand you and dzonatas well enough to go out and > write another, completely unofficial, possibly experimental draft for > the group. then maybe a little bit of PHP and JavaScript to > demonstrate a few of the features. > > again, thanks for the comments (and this is by no means the end of the > commentary on my extended type system.) i think it's just easier for > me to have a conversation about it after having real documents and a > sample implementation to look at. > > i'm going to probably drop out of the conversation for a week as i go > off and work on this stuff. i'll keep a lookout for additional > comments, and try to address them in my next draft. but i probably > won't have bandwidth to discuss them for a week or so. > > -cheers > -meadhbh > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > On Fri, Jul 16, 2010 at 10:41 PM, Morgaine > wrote: > > That's correct, I was describing flows at the capability level, not at > the > > transport level. The transport is exactly as you deduced, namely with > > separate transports for capability request-response and for asynchronous > > event messaging. > > > > When you send an ENABLE to the capability that controls a particular > > asynchronous event stream, you receive back the normal capability OK > > response on the same channel as the request (as expected), but the event > > messaging that this enables occurs on a distinct channel at the transport > > level. > > > > This makes a lot of sense for practical implementations, because event > > messaging requires high bandwidth and low latency and so it is best > handled > > on a separate transport and using the most efficient form of > serialization. > > > > As an implementation example, the OK response from the request to the > > capability could return the IP address and port of the event messaging > > source host, the client would open a TCP stream to it, the source host > would > > send events asynchronously down the pipe, and the client's event listener > > would dispatch the event frames to appropriate event handlers as the > > messages arrive. > > > > Different event-generating capabilities could choose to return different > > IP:port pairs to harness dynamic load-balanced server pools and to > provide > > parallel pathing, or they could choose to share a common event transport > --- > > these would be simple site configuration choices. > > > > Note that this is highly scalable, since it allows any number of servers > to > > participate in event generation and distribution. No longer do updates > have > > to come from a single, horribly overloaded and totally non-scalable > > simulator host. > > > > Consistent with David's regular exhortations, nothing in the above > precludes > > this model from working in the legacy deployment architectures of SL and > > Opensim: single simulator operation is still supported by the design, > but > > it offers additional capability for more scalable deployments. > > > > > > Morgaine. > > > > > > > > > > > > ===================================== > > > > On Fri, Jul 16, 2010 at 7:45 PM, Meadhbh Hamrick > > wrote: > >> > >> Interesting. I had been thinking that the message semantics would > require > >> a response on the same channel as the request. What you're talking about > >> seems to be a little higher level than what I'm pitching. (Thx for > pointing > >> out I wasn't clear about this) > >> > >> So.. the way I'm modeling it is that you have message interactions that > >> are tied to the same transport session. So if you ask for something with > >> http(s), you get it back via http(s) on the same connection. > >> > >> But it's definitely true that an application layer entity can coordinate > >> messages, only I think we should make a "virtual" connection that spans > >> actual connections. > >> > >> But I still think it's advantageous to think of interaction patterns in > >> terms of message flows over specific connections, otherwise we have to > start > >> adding application layer transaction id's to correlate responses to > >> requests. Also, since trust seems to be associated with connections (by > way > >> of (D)TLS), it's probably a good idea to not cross trust boundaries in > >> interactions across connections, otherwise we would have to model that > in > >> the application layer as well. > >> > >> At the end of the day, we have message patterns that look like: > >> > >> * send, no reply expected > >> * request, response expected > >> and > >> * unsolicited message. > >> > >> The first two can be modeled with request/response, but the last one has > >> unique characteristics that must be modeled. > >> > >> -cheers > >> -meadhbh > >> > >> On Jul 16, 2010 11:05 AM, "Morgaine" > >> wrote: > >> > >> Considering asynchronous messages to be emitted in response to a CRUD > >> operation on an appropriate resource fits in perfectly with the notion > of > >> Capabilities though. They ARE solicited, by a request to a resource. > >> > >> As in my earlier example of the text-only client, the CRUD operation > >> UPDATE(scenegraph_updates_capability, ENABLE) was not invoked by the > client > >> (or it was invoked with the argument DISABLE), and hence that resource > saves > >> time and bandwidth by not sending the unwanted scenegraph updates. If > >> instead the resource were set to ENABLE, those update messages would > >> certainly be appearing in response to the ENABLE request, so it's a > natural > >> interpretation. And of course it's very helpful to have such events > >> controlled by a capability. > >> > >> The alternative model in which events are considered normal CRUD > >> operations on an event queue in the reverse direction is actually > incorrect, > >> because then those operations would require responses themselves, and > that's > >> not what we want. Events don't fit the synchronous request-response > model, > >> because they're not synchronous, and are ill-suited to a 2-way > >> request-response paradigm for every event message. > >> > >> That's why I prefer the unidirectional model in which events occur as a > >> sequence of zero or more messages in response to a normal CRUD > operation. > >> It's a clean model because the responses travel in the reverse direction > >> perfectly naturally (since they're responses) and do not themselves > require > >> further ACKs. It's also justified because, after all, we will require a > >> means of enabling / disabling updates and other asynchronous event > >> notifications. This model kills two birds with one stone, and it's a > >> natural fit for capabilities. > >> > >> > >> Morgaine. > >> > >> > >> > >> > >> ================================== > >> > >> On Fri, Jul 16, 2010 at 5:09 PM, Meadhbh Hamrick > >> wrote: > >> > > >> > > EVENT is not a... > >> > >> _______________________________________________ > >> vwrap mailing list > >> vwrap@ietf.org > >> https://www.ietf.org/mailman/listinfo/vwrap > >> > > > > > > _______________________________________________ > > vwrap mailing list > > vwrap@ietf.org > > https://www.ietf.org/mailman/listinfo/vwrap > > > > > --0016367b60a6f7245b048b905ea2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Righto Meadhbh, I'm looking forward to that.

It's worth noti= ng that this design pattern works for many services and subsystems in our k= ind of VW architecture.=A0 Wherever a capability enables a service that ope= rates over a separate transport, the capability grant can supply dynamic IP= :port pairs for the transport and hence quite trivially harness load balanc= ing for the service in question.

We can certainly apply this not only to object updates but also to grou= p IM, world notifications, and to search.=A0 Any region-specific assets suc= h as terrain also fit the model well for load-balanced streaming, and even = baked avatars served from load-balanced pools fit the model.

It's a generic design that is much more flexible and controllable t= han access dispersal to dynamic pools through DNS or through load balancers= , and it provides good security as well, and no single point of failure.

Morgaine.




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

On Sat, Jul 17, 2010 at 7:27 AM, Meadhbh Hamrick <ohmeadhbh@gmail.com<= /a>> wrote:
okay. i think i u= nderstand you and dzonatas well enough to go out and
write another, completely unofficial, possibly experimental draft for
the group. then maybe a little bit of PHP and JavaScript to
demonstrate a few of the features.

again, thanks for the comments (and this is by no means the end of the
commentary on my extended type system.) i think it's just easier for me to have a conversation about it after having real documents and a
sample implementation to look at.

i'm going to probably drop out of the conversation for a week as i go off and work on this stuff. i'll keep a lookout for additional
comments, and try to address them in my next draft. but i probably
won't have bandwidth to discuss them for a week or so.

-cheers
-meadhbh
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadh= bh.org/ * OhMeadhbh@gmail.com



On Fri, Jul 16, 2010 at 10:41 PM, Morgaine
<morgaine.dinova@googlemail.com> wrote:
> That's correct, I was describing flows at the capability level, no= t at the
> transport level.=A0 The transport is exactly as you deduced, namely wi= th
> separate transports for capability request-response and for asynchrono= us
> event messaging.
>
> When you send an ENABLE to the capability that controls a particular > asynchronous event stream, you receive back the normal capability OK > response on the same channel as the request (as expected), but the eve= nt
> messaging that this enables occurs on a distinct channel at the transp= ort
> level.
>
> This makes a lot of sense for practical implementations, because event=
> messaging requires high bandwidth and low latency and so it is best ha= ndled
> on a separate transport and using the most efficient form of serializa= tion.
>
> As an implementation example, the OK response from the request to the<= br> > capability could return the IP address and port of the event messaging=
> source host, the client would open a TCP stream to it, the source host= would
> send events asynchronously down the pipe, and the client's event l= istener
> would dispatch the event frames to appropriate event handlers as the > messages arrive.
>
> Different event-generating capabilities could choose to return differe= nt
> IP:port pairs to harness dynamic load-balanced server pools and to pro= vide
> parallel pathing, or they could choose to share a common event transpo= rt ---
> these would be simple site configuration choices.
>
> Note that this is highly scalable, since it allows any number of serve= rs to
> participate in event generation and distribution.=A0 No longer do upda= tes have
> to come from a single, horribly overloaded and totally non-scalable > simulator host.
>
> Consistent with David's regular exhortations, nothing in the above= precludes
> this model from working in the legacy deployment architectures of SL a= nd
> Opensim:=A0 single simulator operation is still supported by the desig= n, but
> it offers additional capability for more scalable deployments.
>
>
> Morgaine.
>
>
>
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> On Fri, Jul 16, 2010 at 7:45 PM, Meadhbh Hamrick <ohmeadhbh@gmail.com>
> wrote:
>>
>> Interesting. I had been thinking that the message semantics would = require
>> a response on the same channel as the request. What you're tal= king about
>> seems to be a little higher level than what I'm pitching. (Thx= for pointing
>> out I wasn't clear about this)
>>
>> So.. the way I'm modeling it is that you have message interact= ions that
>> are tied to the same transport session. So if you ask for somethin= g with
>> http(s), you get it back via http(s) on the same connection.
>>
>> But it's definitely true that an application layer entity can = coordinate
>> messages, only I think we should make a "virtual" connec= tion that spans
>> actual connections.
>>
>> But I still think it's advantageous to think of interaction pa= tterns in
>> terms of message flows over specific connections, otherwise we hav= e to start
>> adding application layer transaction id's to correlate respons= es to
>> requests. Also, since trust seems to be associated with connection= s (by way
>> of (D)TLS), it's probably a good idea to not cross trust bound= aries in
>> interactions across connections, otherwise we would have to model = that in
>> the application layer as well.
>>
>> At the end of the day, we have message patterns that look like: >>
>> * send, no reply expected
>> * request, response expected
>> and
>> * unsolicited message.
>>
>> The first two can be modeled with request/response, but the last o= ne has
>> unique characteristics that must be modeled.
>>
>> -cheers
>> -meadhbh
>>
>> On Jul 16, 2010 11:05 AM, "Morgaine" <morgaine.dinova@googlemail.com> >> wrote:
>>
>> Considering asynchronous messages to be emitted in response to a C= RUD
>> operation on an appropriate resource fits in perfectly with the no= tion of
>> Capabilities though.=A0 They ARE solicited, by a request to a reso= urce.
>>
>> As in my earlier example of the text-only client, the CRUD operati= on
>> UPDATE(scenegraph_updates_capability, ENABLE) was not invoked by t= he client
>> (or it was invoked with the argument DISABLE), and hence that reso= urce saves
>> time and bandwidth by not sending the unwanted scenegraph updates.= =A0 If
>> instead the resource were set to ENABLE, those update messages wou= ld
>> certainly be appearing in response to the ENABLE request, so it= 9;s a natural
>> interpretation.=A0 And of course it's very helpful to have suc= h events
>> controlled by a capability.
>>
>> The alternative model in which events are considered normal CRUD >> operations on an event queue in the reverse direction is actually = incorrect,
>> because then those operations would require responses themselves, = and that's
>> not what we want.=A0 Events don't fit the synchronous request-= response model,
>> because they're not synchronous, and are ill-suited to a 2-way=
>> request-response paradigm for every event message.
>>
>> That's why I prefer the unidirectional model in which events o= ccur as a
>> sequence of zero or more messages in response to a normal CRUD ope= ration.
>> It's a clean model because the responses travel in the reverse= direction
>> perfectly naturally (since they're responses) and do not thems= elves require
>> further ACKs.=A0 It's also justified because, after all, we wi= ll require a
>> means of enabling / disabling updates and other asynchronous event=
>> notifications.=A0 This model kills two birds with one stone, and i= t's a
>> natural fit for capabilities.
>>
>>
>> Morgaine.
>>
>>
>>
>>
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>> On Fri, Jul 16, 2010 at 5:09 PM, Meadhbh Hamrick <ohmeadhbh@gmail.com>
>> wrote:
>> >
>> > > EVENT is not a...
>>
>> _______________________________________________
>> vwrap mailing list
>> vwrap@ietf.org
>> https://www.ietf.org/mailman/listinfo/vwrap
>>
>
>
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>
>

--0016367b60a6f7245b048b905ea2-- From dzonatas@gmail.com Sun Jul 18 06:48:56 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A73593A68C6 for ; Sun, 18 Jul 2010 06:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_20=-0.74, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RYsvFdTWXySM for ; Sun, 18 Jul 2010 06:48:51 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id BF24B3A68D4 for ; Sun, 18 Jul 2010 06:48:50 -0700 (PDT) Received: by pwj1 with SMTP id 1so2055611pwj.31 for ; Sun, 18 Jul 2010 06:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=QUcpENa6FpIkbMzU12dotFWcOBALDMSa7EvYLvyoocw=; b=K5b8tU47C8yJrtcdL0CXLu04S2WK/u4ipi9PLngXGb56ybT0nfCwu3i4ggzRl9egmY io/MLaadOuW0kcD1uWXvXrX79EMqUZPAiec+xFCP2SJI5GPmsVP+kHxkfS/B2U1puStz B/+OcH/E/SiNG2Vu/ec6MBz3zhK1VjuoWi04A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=Box1396z98z9qHOz/5MUe5DP3ru8360JMXXURTda3fZigjlhVNkgrAnhSAL2vG85M2 m9HaGzKJuYexSYMUOAl2jWx47tZeNhpDFJYgSRXEIK/D5V2998fReuPyVsGDbJV4RmeF wHrQ83Ie88sylWPibmgOAZVmsOo+JlUyZxq3s= Received: by 10.114.130.16 with SMTP id c16mr5151544wad.20.1279460928463; Sun, 18 Jul 2010 06:48:48 -0700 (PDT) Received: from [192.168.0.50] (adsl-69-105-197-115.dsl.scrm01.pacbell.net [69.105.197.115]) by mx.google.com with ESMTPS id g4sm55511520wae.14.2010.07.18.06.48.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 18 Jul 2010 06:48:47 -0700 (PDT) Message-ID: <4C43091E.7030209@gmail.com> Date: Sun, 18 Jul 2010 07:01:02 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: Meadhbh Hamrick , vwrap@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [vwrap] thinking about LLIDL and the future X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2010 13:48:56 -0000 Meadhbh Hamrick wrote: > okay. i think i understand you and dzonatas well enough to go out and > write another, completely unofficial, possibly experimental draft for > the group. then maybe a little bit of PHP and JavaScript to > demonstrate a few of the features. A little more for us to think about... from actual usage... The simple queries that Icesphere puts together are something like: GET http://host:port/abc/def/uuid. If it finds many of these simple queries found in the queue, then it combines them all into a single complex query: POST http://host:port/abd/def/s. Technical detail on transport, the single letter "s" is a false UUID to denote a list of UUIDs in the request. Due to such automatic query transition above, you can probably guess at reasons why Icesphere avoids the event queue resource, as described in VWRAP. I look at VWRAPs event queue as another possible transition and technical detail on transport. When I mentioned bidirectional earlier, I actually meant fully bidirectional and not just simply request/response. For example, in Icesphere, the client sends a query to load an asset for an inventory item, which returns HTTP_OK|HTTP_ACCEPTED status. The resource is released after that status. When the server has the asset, it send a query that the asset is loaded to the client, as a separate resource. That is a capability that is obviously not active for those that don't support full bidirectional queries due to possible firewall that only allow unidirectional queries. I think I rather go with QUERY rather then request/response mainly to make direction more significant and to make the request/response a technical detail of the transport. I started to type lots of detail here, yet my coffee pot is empty. To expand you usage of EVENT into a QUERY we just need to know the pivotal data for transitions, like UUIDs. From ohmeadhbh@gmail.com Sun Jul 18 09:23:17 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B78C63A687D for ; Sun, 18 Jul 2010 09:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.863 X-Spam-Level: X-Spam-Status: No, score=-0.863 tagged_above=-999 required=5 tests=[AWL=-1.278, BAYES_40=-0.185, J_CHICKENPOX_41=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 HvsYw5GGgwH7 for ; Sun, 18 Jul 2010 09:23:16 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 3824E3A6936 for ; Sun, 18 Jul 2010 09:23:16 -0700 (PDT) Received: by qwe5 with SMTP id 5so1564979qwe.31 for ; Sun, 18 Jul 2010 09:23:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=dBsqAbPzVJlHwIyi+gpq2zxxqOVQCl9Vgkfk1yd/FfU=; b=F9VZHTq0tCvaBbBTj1QYAhcYLrQKGg/pPyYuUsaVyIXjdtwWTHcMdI78vyMsA17prn nwtjH830vNVoljw5CgiT8i0bixN9XXlUklr920vj5M5ZjwuLVKAH25NlvAdvi/O5PSu5 iTsH3ufUauNzfDg0jKkp/3wB/x78Qxvhd9d30= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=OBVOfiJdhYCkAzrxvkqnFt6fpHVN3tV0kA3zcf/IqFiaYDezI71p+lCY7lI8tFqw8B 8aBKF/NhrLmVKVoPBbA5EC9HMh23T/L7u3YZraS7hjpft3Z4z8v0zGiZUSZO6OjpuRA9 qmtDm9MoQXId9DXx0XZAmZKCQ+Lqjv44CmjBM= Received: by 10.224.18.22 with SMTP id u22mr3355499qaa.18.1279470209216; Sun, 18 Jul 2010 09:23:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.13.225 with HTTP; Sun, 18 Jul 2010 09:23:09 -0700 (PDT) From: Meadhbh Hamrick Date: Sun, 18 Jul 2010 09:23:09 -0700 Message-ID: To: vwrap@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [vwrap] looking for good summaries of web capabilities X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2010 16:23:17 -0000 hey peeps, i want to stuff a reference to web capabilities in the intro, revised foundation and auth documents, but i'm having a problem finding a document that's "just right." if you start searching for "capabilities" on google, you find a lot of references to Henry Levy,s "Capability Based Computer Systems" ( available online at http://www.cs.washington.edu/homes/levy/capabook/ .) it's a good book, but is really focused on capability based addressing systems for systems that use caps locally (not web caps.) references on the wikipedia seem to have the same problem; they're focused on caps for replacing ACLs locally on computer systems. Miller, et al., published "Myths of Capabilities Demolished" (available online at http://srl.cs.jhu.edu/pubs/SRL2003-02.pdf ,) but the tone of the paper is wrong for my needs. i need something that discusses what caps are, not something that goes into detail about why they're at least as good as ACLs. Miller also wrote a pretty good paper called "robust composition: towards a unified approach to access control and concurrency control" but it's focused on explaining caps in terms of miller's E rights language and KeyCOS operating system. i guess what i'm looking for is a paper that briefly describes the "confused deputy problem," the object-capability security model and how web capabilities work (independent of operating system and implementation language.) if i can't find one "soon," like in the next couple of weeks, i'm probably going to write my own, possibly adding a motivation section describing how the confused deputy is more of a problem in "loosely coupled" systems and maybe a bit about client side capabilities. but before i do that, i figured i would ask if anyone knows of a simple paper on webcaps? -cheers, all. -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com From barryleiba.mailing.lists@gmail.com Thu Jul 22 09:05:39 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 526083A67B3 for ; Thu, 22 Jul 2010 09:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=-0.050, 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 v643Orlk07AP for ; Thu, 22 Jul 2010 09:05:38 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 642EA3A6359 for ; Thu, 22 Jul 2010 09:05:37 -0700 (PDT) Received: by mail-pw0-f44.google.com with SMTP id 1so4386253pwj.31 for ; Thu, 22 Jul 2010 09:05:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to:date :message-id:subject:from:to:content-type; bh=ak995UrRb1Rz6UFFqiv3uS9Py9IEwVpxRP55BB6z38M=; b=GCYjon3V++fFvkZyKLpZnTBAMcmvf062+ivkiarUEeI6ntTyRuvTFSHMG21Mx42fAw mEgASDt/ocR8mLgt95li0/U4Qieai/LDDtfRFvhYIqbNypcFZcyjskkvQe8yYnqKMQHg XIzZmB6eOOD9H6yo8eR9rOK6GGffiqwYCitmM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=CgAkIpmpuLOVJEHmTj+wQUnYKgSPyxHzW03rof7sCWudbZHpLrFoJQsto5458lo0Y0 1NPbwI1A6H0LotZgjPQIqwGtA7SJDJwcm2yJg/2PYbqwFPAmllGQ+FiZ5rY1RVF7yP+4 nXwWYjz7IKNp2NE+xVpo1tfSUEV6ldvhBkGro= MIME-Version: 1.0 Received: by 10.142.141.8 with SMTP id o8mr1537833wfd.298.1279814754883; Thu, 22 Jul 2010 09:05:54 -0700 (PDT) Received: by 10.42.1.136 with HTTP; Thu, 22 Jul 2010 09:05:54 -0700 (PDT) Date: Thu, 22 Jul 2010 12:05:54 -0400 Message-ID: From: Barry Leiba To: vwrap@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [vwrap] Moving ahead with draft-ietf-vwrap-intro X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 16:05:39 -0000 Since there's been no discussion, yet, about "Introduction and Goals" http://tools.ietf.org/html/draft-ietf-vwrap-intro ...we should consider moving ahead with it. To that end: 1. Meadhbh, is there anything outstanding that you think needs to be addressed? Any specific input you need from the working group? 2. David, can you get the IPR statement on Meadhbh's original version https://datatracker.ietf.org/ipr/1294/ ...updated, if it's still applicable to the WG version? If it's not still applicable, we'd need you to tell us that. 3. Working group: please review the document and discuss any issues with it. Joshua and I will also appreciate comments saying "I've reviewed it, and it's ready to go." Barry, as chair From ohmeadhbh@gmail.com Thu Jul 22 09:13:39 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10FA23A6BEB for ; Thu, 22 Jul 2010 09:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.389, 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 Hxnx+ciJ3yC8 for ; Thu, 22 Jul 2010 09:13:36 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id C47283A67B3 for ; Thu, 22 Jul 2010 09:13:35 -0700 (PDT) Received: by qwe5 with SMTP id 5so3334324qwe.31 for ; Thu, 22 Jul 2010 09:13:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=CdGqd+EbTg2LZYD64tnkfRGA4g0mK5Lgf3dSacHnbqo=; b=WktXtA0Qgekfm87DzEiseZbpQrS+xbFKYERFLvwdIz3EeVqPOdit3Nhg41Dzri/q7F ev53qnsZ5d6dxJScQaSH+Sbq+jHmIzVgkWutrDkhmSxh2HZLr4QmdRczz04AZg6F8wxY od4LomE6A0uC7A1mqyB+moagjpV5W1Wj4IVGs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=rIAGVOh09KJv2eP6G8MO0gtUsApWq6sUOMizhTY8b2w2DcYWzweqSXVExEf66TmMAJ cni5Mec94UWMw0DMA19Xt/525Gqox1cB2HPSQ/CYcwCgav5H78RlZxRrBqsekO4SviPB yDY7vA2uvuZmjuMwPHd1Z48mmTwZjywDP6+aY= Received: by 10.224.79.77 with SMTP id o13mr1296741qak.206.1279815232713; Thu, 22 Jul 2010 09:13:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.13.225 with HTTP; Thu, 22 Jul 2010 09:13:32 -0700 (PDT) In-Reply-To: References: From: Meadhbh Hamrick Date: Thu, 22 Jul 2010 09:13:32 -0700 Message-ID: To: barryleiba@computer.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] Moving ahead with draft-ietf-vwrap-intro X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 16:13:39 -0000 i don't think there are any outstanding issues with the intro draft. -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Thu, Jul 22, 2010 at 9:05 AM, Barry Leiba wrote: > Since there's been no discussion, yet, about "Introduction and Goals" > =A0 http://tools.ietf.org/html/draft-ietf-vwrap-intro > ...we should consider moving ahead with it. =A0To that end: > > 1. Meadhbh, is there anything outstanding that you think needs to be > addressed? =A0Any specific input you need from the working group? > > 2. David, can you get the IPR statement on Meadhbh's original version > =A0 https://datatracker.ietf.org/ipr/1294/ > ...updated, if it's still applicable to the WG version? =A0If it's not > still applicable, we'd need you to tell us that. > > 3. Working group: please review the document and discuss any issues > with it. =A0Joshua and I will also appreciate comments saying "I've > reviewed it, and it's ready to go." > > Barry, as chair > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > From morgaine.dinova@googlemail.com Thu Jul 22 13:44:56 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E3543A686D for ; Thu, 22 Jul 2010 13:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.776 X-Spam-Level: X-Spam-Status: No, score=-1.776 tagged_above=-999 required=5 tests=[AWL=0.200, 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 8FX4d89cLvLN for ; Thu, 22 Jul 2010 13:44:54 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 507433A680D for ; Thu, 22 Jul 2010 13:44:53 -0700 (PDT) Received: by wwj40 with SMTP id 40so3214196wwj.13 for ; Thu, 22 Jul 2010 13:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=MUNdrRsQDtj/l5DjhzHGKlulZJwoF4Tsov+x0M/WoOA=; b=lvQEWWnA/1SkLc8XTqJzIGecQR13vfy2dGOIkK37ezC3BmE/efTlhh0SEAOx8sE3lg 8WP0uMtJiFNENcIwqAEIAznDuVqY7L1i9DrR1iW3cNJymR/5ed+NCwdpNwQ+aB/TPEOh mQhlkVDLj4pSDzUtbo0SWCoMrryezVha8i4oI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=mKpsTHdnLp9kF/AaSUbyCsihL9LMbpggc9Acb/pUXeivgHZ5TBXZYdgi1Rx3pguTaP NkYS2GvCwgAelAzMptu1/9rCraK9Z14EBjf55di0JrmL8OWEo5zeIQ/kitMTb7fVaHZv K5E55DjaSM4q2Ze5NXBfGzS8g4BsD9bt2p8ik= MIME-Version: 1.0 Received: by 10.227.156.11 with SMTP id u11mr2448058wbw.146.1279831510915; Thu, 22 Jul 2010 13:45:10 -0700 (PDT) Received: by 10.216.50.208 with HTTP; Thu, 22 Jul 2010 13:45:10 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 Jul 2010 21:45:10 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016363ba63a94a3b8048bfffe34 Subject: Re: [vwrap] Moving ahead with draft-ietf-vwrap-intro X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 20:44:56 -0000 --0016363ba63a94a3b8048bfffe34 Content-Type: text/plain; charset=ISO-8859-1 Barry, I've been reviewing the Intro document for several days now, and there are important issues there that will need a certain amount of change. I don't expect it to be very contentious (basically the old OGP worldview needs to be brought into line with what's already been discussed in the group), but I will need some more days of work on it next week. Hopefully it won't take me too long. Morgaine. ==================================== On Thu, Jul 22, 2010 at 5:13 PM, Meadhbh Hamrick wrote: > i don't think there are any outstanding issues with the intro draft. > > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > On Thu, Jul 22, 2010 at 9:05 AM, Barry Leiba > wrote: > > Since there's been no discussion, yet, about "Introduction and Goals" > > http://tools.ietf.org/html/draft-ietf-vwrap-intro > > ...we should consider moving ahead with it. To that end: > > > > 1. Meadhbh, is there anything outstanding that you think needs to be > > addressed? Any specific input you need from the working group? > > > > 2. David, can you get the IPR statement on Meadhbh's original version > > https://datatracker.ietf.org/ipr/1294/ > > ...updated, if it's still applicable to the WG version? If it's not > > still applicable, we'd need you to tell us that. > > > > 3. Working group: please review the document and discuss any issues > > with it. Joshua and I will also appreciate comments saying "I've > > reviewed it, and it's ready to go." > > > > Barry, as chair > > _______________________________________________ > > vwrap mailing list > > vwrap@ietf.org > > https://www.ietf.org/mailman/listinfo/vwrap > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > --0016363ba63a94a3b8048bfffe34 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Barry, I've been reviewing the Intro document for several days now, and= there are important issues there that will need a certain amount of change= .=A0 I don't expect it to be very contentious (basically the old OGP wo= rldview needs to be brought into line with what's already been discusse= d in the group), but I will need some more days of work on it next week.
Hopefully it won't take me too long.


Morgaine.


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

O= n Thu, Jul 22, 2010 at 5:13 PM, Meadhbh Hamrick <ohmeadhbh@gmail.com> wrote:=
i don't think= there are any outstanding issues with the intro draft.

--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadh= bh.org/ * OhMeadhbh@gmail.com



On Thu, Jul 22, 2010 at 9:05 AM, Barry Leiba
<barryleiba.mailin= g.lists@gmail.com> wrote:
> Since there's been no discussion, yet, about "Introduction an= d Goals"
> =A0 http://tools.ietf.org/html/draft-ietf-vwrap-intro
> ...we should consider moving ahead with it. =A0To that end:
>
> 1. Meadhbh, is there anything outstanding that you think needs to be > addressed? =A0Any specific input you need from the working group?
>
> 2. David, can you get the IPR statement on Meadhbh's original vers= ion
> =A0 https://datatracker.ietf.org/ipr/1294/
> ...updated, if it's still applicable to the WG version? =A0If it&#= 39;s not
> still applicable, we'd need you to tell us that.
>
> 3. Working group: please review the document and discuss any issues > with it. =A0Joshua and I will also appreciate comments saying "I&= #39;ve
> reviewed it, and it's ready to go."
>
> Barry, as chair
> _______________________________________________
> vwrap mailing list
> vwrap@ietf.org
> https://www.ietf.org/mailman/listinfo/vwrap
>
_______________________________________________
vwrap mailing list
vwrap@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/vwrap

--0016363ba63a94a3b8048bfffe34-- From ohmeadhbh@gmail.com Thu Jul 22 15:05:43 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43CEC3A69DF for ; Thu, 22 Jul 2010 15:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.345, 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 2URPlZ6B4pPe for ; Thu, 22 Jul 2010 15:05:42 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id D47BD3A6A03 for ; Thu, 22 Jul 2010 15:05:41 -0700 (PDT) Received: by qwe5 with SMTP id 5so3515588qwe.31 for ; Thu, 22 Jul 2010 15:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=tqqQmrP40wVcS2K4QKULa10dnPv+steyCVKoLFEcRRY=; b=LT1fZgntogdWmOl1gjNr/BAkohwKazTJHoiqa5vBtj9OXi++DQBNowrfJ9oXGqJSsj qjMmrcnBitOSkm2cLy0PYNcJijv+FloPxGmWT1R/GXCf4Ml8RgQFLjL7j/A1JptNr/bF WnBTzj+9sL65yJ/mDv91PbSr1Ukzj+WWC2aGI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=ttYaiC1R5GGkmhF8qX6jzhHtOLKPlzsCbcnSwapZzstpzHN8UocaOBwb9tmAB4z6gY 7mNjXnb1hu9+K4v7MQzHzNm4rf5os2tHSOP48EPypVVQVtJePTNBa5QJ6hMPgLyFc+f+ uHRpveF+9FHet89oFEjGNjURJbeIBIGb+jRi0= Received: by 10.224.47.85 with SMTP id m21mr1774275qaf.149.1279836359121; Thu, 22 Jul 2010 15:05:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.13.225 with HTTP; Thu, 22 Jul 2010 15:05:39 -0700 (PDT) In-Reply-To: References: From: Meadhbh Hamrick Date: Thu, 22 Jul 2010 15:05:39 -0700 Message-ID: To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] Moving ahead with draft-ietf-vwrap-intro X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 22:05:43 -0000 morgaine! you're frightening me! i think we should definitely support the tourist model, but please don't try to take out the bits that support fixed / locked down grids. there are many of us who will be implementing this style of VW. -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Thu, Jul 22, 2010 at 1:45 PM, Morgaine wrote: > Barry, I've been reviewing the Intro document for several days now, and > there are important issues there that will need a certain amount of chang= e. > I don't expect it to be very contentious (basically the old OGP worldview > needs to be brought into line with what's already been discussed in the > group), but I will need some more days of work on it next week. > > Hopefully it won't take me too long. > > > Morgaine. > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > On Thu, Jul 22, 2010 at 5:13 PM, Meadhbh Hamrick > wrote: >> >> i don't think there are any outstanding issues with the intro draft. >> >> -- >> meadhbh hamrick * it's pronounced "maeve" >> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> >> >> >> On Thu, Jul 22, 2010 at 9:05 AM, Barry Leiba >> wrote: >> > Since there's been no discussion, yet, about "Introduction and Goals" >> > =A0 http://tools.ietf.org/html/draft-ietf-vwrap-intro >> > ...we should consider moving ahead with it. =A0To that end: >> > >> > 1. Meadhbh, is there anything outstanding that you think needs to be >> > addressed? =A0Any specific input you need from the working group? >> > >> > 2. David, can you get the IPR statement on Meadhbh's original version >> > =A0 https://datatracker.ietf.org/ipr/1294/ >> > ...updated, if it's still applicable to the WG version? =A0If it's not >> > still applicable, we'd need you to tell us that. >> > >> > 3. Working group: please review the document and discuss any issues >> > with it. =A0Joshua and I will also appreciate comments saying "I've >> > reviewed it, and it's ready to go." >> > >> > Barry, as chair >> > _______________________________________________ >> > vwrap mailing list >> > vwrap@ietf.org >> > https://www.ietf.org/mailman/listinfo/vwrap >> > >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > From ohmeadhbh@gmail.com Thu Jul 22 15:06:40 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 071F83A69DF for ; Thu, 22 Jul 2010 15:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.311, 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 wRwT1wgOxa+2 for ; Thu, 22 Jul 2010 15:06:39 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id E30C33A6847 for ; Thu, 22 Jul 2010 15:06:38 -0700 (PDT) Received: by gxk1 with SMTP id 1so5250295gxk.31 for ; Thu, 22 Jul 2010 15:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=y1xm/xeTLOufAuAIrCbt+tsR/JjfWY7fvKTafg+96kg=; b=GNeS8PmVMKB2bpYgevJzlhkadMjk9WZDjtjk7ll5ZsjDvUcZDNWLrAli9ybzCNtUTF rf7EQarfqvazhnstXp7WOaOugdGpzD1C1IeovlXaidW1IO41/b7MGxKjPIJV9sM3pvz0 jAMm4tupOWNB+0O9LNmDj/ci110OlLoRt5Jgo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=ptomp8lr1UxyHAqnvLvsyhn0EoG2q50jqJPI391MBEacCSbGiO1yLkKwTixsCLBI+4 GLAgTnUgHNDmxAKT1UPEoGSZL/ceGWhoNSmrzO/NsoYlsU6HwIIVddyqEiwY1d3bG+f9 EWjx9NanTpW4LskNlHHeZpt1B56q1ZQlpRois= Received: by 10.150.214.11 with SMTP id m11mr4702970ybg.315.1279836416244; Thu, 22 Jul 2010 15:06:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.13.225 with HTTP; Thu, 22 Jul 2010 15:06:36 -0700 (PDT) In-Reply-To: References: From: Meadhbh Hamrick Date: Thu, 22 Jul 2010 15:06:36 -0700 Message-ID: To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] Moving ahead with draft-ietf-vwrap-intro X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 22:06:40 -0000 in other words... let's not start a fight over whether your model is supported or not. if you write up some words that support the tourist model, but don't make the fixed grid impossible, i'm all for it. -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Thu, Jul 22, 2010 at 3:05 PM, Meadhbh Hamrick wrot= e: > morgaine! you're frightening me! > > i think we should definitely support the tourist model, but please > don't try to take out the bits that support fixed / locked down grids. > there are many of us who will be implementing this style of VW. > > -cheers > -meadhbh > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > On Thu, Jul 22, 2010 at 1:45 PM, Morgaine > wrote: >> Barry, I've been reviewing the Intro document for several days now, and >> there are important issues there that will need a certain amount of chan= ge. >> I don't expect it to be very contentious (basically the old OGP worldvie= w >> needs to be brought into line with what's already been discussed in the >> group), but I will need some more days of work on it next week. >> >> Hopefully it won't take me too long. >> >> >> Morgaine. >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> On Thu, Jul 22, 2010 at 5:13 PM, Meadhbh Hamrick >> wrote: >>> >>> i don't think there are any outstanding issues with the intro draft. >>> >>> -- >>> meadhbh hamrick * it's pronounced "maeve" >>> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >>> >>> >>> >>> On Thu, Jul 22, 2010 at 9:05 AM, Barry Leiba >>> wrote: >>> > Since there's been no discussion, yet, about "Introduction and Goals" >>> > =A0 http://tools.ietf.org/html/draft-ietf-vwrap-intro >>> > ...we should consider moving ahead with it. =A0To that end: >>> > >>> > 1. Meadhbh, is there anything outstanding that you think needs to be >>> > addressed? =A0Any specific input you need from the working group? >>> > >>> > 2. David, can you get the IPR statement on Meadhbh's original version >>> > =A0 https://datatracker.ietf.org/ipr/1294/ >>> > ...updated, if it's still applicable to the WG version? =A0If it's no= t >>> > still applicable, we'd need you to tell us that. >>> > >>> > 3. Working group: please review the document and discuss any issues >>> > with it. =A0Joshua and I will also appreciate comments saying "I've >>> > reviewed it, and it's ready to go." >>> > >>> > Barry, as chair >>> > _______________________________________________ >>> > vwrap mailing list >>> > vwrap@ietf.org >>> > https://www.ietf.org/mailman/listinfo/vwrap >>> > >>> _______________________________________________ >>> vwrap mailing list >>> vwrap@ietf.org >>> https://www.ietf.org/mailman/listinfo/vwrap >> >> >> _______________________________________________ >> vwrap mailing list >> vwrap@ietf.org >> https://www.ietf.org/mailman/listinfo/vwrap >> >> > From morgaine.dinova@googlemail.com Fri Jul 23 01:07:35 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0950D3A699F for ; Fri, 23 Jul 2010 01:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.826 X-Spam-Level: X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Dk0sHSXfQGA for ; Fri, 23 Jul 2010 01:07:32 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 24A913A698F for ; Fri, 23 Jul 2010 01:07:31 -0700 (PDT) Received: by wyb40 with SMTP id 40so1407153wyb.31 for ; Fri, 23 Jul 2010 01:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=4z7ftKZR2X0UN57fFn11t4O3raZZ3TOTYF26DqUNhiI=; b=Bwy+ln5HUqWUHd4jk02j3PZPQYPCWb07E3MCpzkTBTUzZrnyVjT7ZpliOJFJYCQKeL VJr/w2LiS14F+8HgcexhL3ddZzNhsnUvXuxz/eDDWvJ92hz1r0LgCqOzEDV9IL84GfjB Dd3KQ6jvIU/K2XWd1nC8mrL7gQGBJkjQfY0u4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=drJ05CcjwhYRKaUaqFQsOkz3GkdpFSv+2AqrfiE0nl8yYDZSVbbgr1czvbGmCqEZhi jea8bFbH/bGkabBzE2aMgsj8+dreIO0tLh49VK7Xtow5nEHJHJXO3A4LcV4OpTb41RuM cAXIOlvogpuBwHCOc5ZGw5tKV6gZRhIOxfXPg= MIME-Version: 1.0 Received: by 10.227.128.82 with SMTP id j18mr2765660wbs.36.1279872463127; Fri, 23 Jul 2010 01:07:43 -0700 (PDT) Received: by 10.216.50.208 with HTTP; Fri, 23 Jul 2010 01:07:43 -0700 (PDT) In-Reply-To: References: Date: Fri, 23 Jul 2010 09:07:43 +0100 Message-ID: From: Morgaine To: vwrap@ietf.org Content-Type: multipart/alternative; boundary=0016e65a078885c9bb048c0987b1 Subject: Re: [vwrap] Moving ahead with draft-ietf-vwrap-intro X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 08:07:35 -0000 --0016e65a078885c9bb048c0987b1 Content-Type: text/plain; charset=ISO-8859-1 I'm a firm supporter of David's position on multiple deployment models, a wide range of which should be possible. Our specifications need to make that flexibility clear instead of hanging on to old language that has its roots in the walled garden model with which we started. I'm also a firm supporter of the IETF's mission statement with regard to interoperability and scalability, which again places upon us a certain duty towards those goals in our documents. I'm trying to improve our protocols and specification on both those fronts. There is certainly nothing to fear. Denying interoperation will always be possible, and trivial to accomplish. Our task is to allow interoperation for those who want it. Morgaine. =================================== On Thu, Jul 22, 2010 at 11:06 PM, Meadhbh Hamrick wrote: > in other words... let's not start a fight over whether your model is > supported or not. if you write up some words that support the tourist > model, but don't make the fixed grid impossible, i'm all for it. > > -cheers > -meadhbh > -- > meadhbh hamrick * it's pronounced "maeve" > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > On Thu, Jul 22, 2010 at 3:05 PM, Meadhbh Hamrick > wrote: > > morgaine! you're frightening me! > > > > i think we should definitely support the tourist model, but please > > don't try to take out the bits that support fixed / locked down grids. > > there are many of us who will be implementing this style of VW. > > > > -cheers > > -meadhbh > > -- > > meadhbh hamrick * it's pronounced "maeve" > > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > > > > > > > > On Thu, Jul 22, 2010 at 1:45 PM, Morgaine > > wrote: > >> Barry, I've been reviewing the Intro document for several days now, and > >> there are important issues there that will need a certain amount of > change. > >> I don't expect it to be very contentious (basically the old OGP > worldview > >> needs to be brought into line with what's already been discussed in the > >> group), but I will need some more days of work on it next week. > >> > >> Hopefully it won't take me too long. > >> > >> > >> Morgaine. > >> > >> > >> > >> ==================================== > >> > >> On Thu, Jul 22, 2010 at 5:13 PM, Meadhbh Hamrick > >> wrote: > >>> > >>> i don't think there are any outstanding issues with the intro draft. > >>> > >>> -- > >>> meadhbh hamrick * it's pronounced "maeve" > >>> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com > >>> > >>> > >>> > >>> On Thu, Jul 22, 2010 at 9:05 AM, Barry Leiba > >>> wrote: > >>> > Since there's been no discussion, yet, about "Introduction and Goals" > >>> > http://tools.ietf.org/html/draft-ietf-vwrap-intro > >>> > ...we should consider moving ahead with it. To that end: > >>> > > >>> > 1. Meadhbh, is there anything outstanding that you think needs to be > >>> > addressed? Any specific input you need from the working group? > >>> > > >>> > 2. David, can you get the IPR statement on Meadhbh's original version > >>> > https://datatracker.ietf.org/ipr/1294/ > >>> > ...updated, if it's still applicable to the WG version? If it's not > >>> > still applicable, we'd need you to tell us that. > >>> > > >>> > 3. Working group: please review the document and discuss any issues > >>> > with it. Joshua and I will also appreciate comments saying "I've > >>> > reviewed it, and it's ready to go." > >>> > > >>> > Barry, as chair > >>> > _______________________________________________ > >>> > vwrap mailing list > >>> > vwrap@ietf.org > >>> > https://www.ietf.org/mailman/listinfo/vwrap > >>> > > >>> _______________________________________________ > >>> vwrap mailing list > >>> vwrap@ietf.org > >>> https://www.ietf.org/mailman/listinfo/vwrap > >> > >> > >> _______________________________________________ > >> vwrap mailing list > >> vwrap@ietf.org > >> https://www.ietf.org/mailman/listinfo/vwrap > >> > >> > > > --0016e65a078885c9bb048c0987b1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm a firm supporter of David's position on multiple deployment mod= els, a wide range of which should be possible.=A0 Our specifications need t= o make that flexibility clear instead of hanging on to old language that ha= s its roots in the walled garden model with which we started.

I'm also a firm supporter of the IETF's mission statement with = regard to interoperability and scalability, which again places upon us a ce= rtain duty towards those goals in our documents.

I'm trying to i= mprove our protocols and specification on both those fronts.

There is certainly nothing to fear.=A0 Denying interoperation will alwa= ys be possible, and trivial to accomplish.=A0 Our task is to allow interope= ration for those who want it.


Morgaine.




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

On Thu, Jul 22, 2010 at 11:06 PM, Meadhbh Ha= mrick <ohmeadhb= h@gmail.com> wrote:
in other words... let's not start a fight over whether your model is supported or not. if you write up some words that support the tourist
model, but don't make the fixed grid impossible, i'm all for it.

-cheers
-meadhbh
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadh= bh.org/ * OhMeadhbh@gmail.com



On Thu, Jul 22, 2010 at 3:05 PM, Me= adhbh Hamrick <ohmeadhbh@gmail.co= m> wrote:
> morgaine! you're frightening me!
>
> i think we should definitely support the tourist model, but please
> don't try to take out the bits that support fixed / locked down gr= ids.
> there are many of us who will be implementing this style of VW.
>
> -cheers
> -meadhbh
> --
> meadhbh hamrick * it's pronounced "maeve"
> @OhMeadhbh * http://= meadhbh.org/ * OhMeadhbh@gmail.c= om
>
>
>
> On Thu, Jul 22, 2010 at 1:45 PM, Morgaine
> <morgaine.dinova@= googlemail.com> wrote:
>> Barry, I've been reviewing the Intro document for several days= now, and
>> there are important issues there that will need a certain amount o= f change.
>> I don't expect it to be very contentious (basically the old OG= P worldview
>> needs to be brought into line with what's already been discuss= ed in the
>> group), but I will need some more days of work on it next week. >>
>> Hopefully it won't take me too long.
>>
>>
>> Morgaine.
>>
>>
>>
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>
>> On Thu, Jul 22, 2010 at 5:13 PM, Meadhbh Hamrick <ohmeadhbh@gmail.com>
>> wrote:
>>>
>>> i don't think there are any outstanding issues with the in= tro draft.
>>>
>>> --
>>> meadhbh hamrick * it's pronounced "maeve"
>>> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh= @gmail.com
>>>
>>>
>>>
>>> On Thu, Jul 22, 2010 at 9:05 AM, Barry Leiba
>>> <barr= yleiba.mailing.lists@gmail.com> wrote:
>>> > Since there's been no discussion, yet, about "In= troduction and Goals"
>>> > =A0 http://tools.ietf.org/html/draft-ietf-vwrap-intr= o
>>> > ...we should consider moving ahead with it. =A0To that en= d:
>>> >
>>> > 1. Meadhbh, is there anything outstanding that you think = needs to be
>>> > addressed? =A0Any specific input you need from the workin= g group?
>>> >
>>> > 2. David, can you get the IPR statement on Meadhbh's = original version
>>> > =A0 https://datatracker.ietf.org/ipr/1294/
>>> > ...updated, if it's still applicable to the WG versio= n? =A0If it's not
>>> > still applicable, we'd need you to tell us that.
>>> >
>>> > 3. Working group: please review the document and discuss = any issues
>>> > with it. =A0Joshua and I will also appreciate comments sa= ying "I've
>>> > reviewed it, and it's ready to go."
>>> >
>>> > Barry, as chair
>>> > _______________________________________________
>>> > vwrap mailing list
>>> > vwrap@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/vwrap
>>> >
>>> _______________________________________________
>>> vwrap mailing list
>>> vwrap@ietf.org
>>> https://www.ietf.org/mailman/listinfo/vwrap
>>
>>
>> _______________________________________________
>> vwrap mailing list
>> vwrap@ietf.org
>> https://www.ietf.org/mailman/listinfo/vwrap
>>
>>
>

--0016e65a078885c9bb048c0987b1-- From ohmeadhbh@gmail.com Fri Jul 23 01:09:37 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A9CD3A696C for ; Fri, 23 Jul 2010 01:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=0.283, 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 rr2fc4HPjo-l for ; Fri, 23 Jul 2010 01:09:36 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id D594F3A689E for ; Fri, 23 Jul 2010 01:09:35 -0700 (PDT) Received: by vws10 with SMTP id 10so1345367vws.31 for ; Fri, 23 Jul 2010 01:09:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=k2zkksn+NyfOG4ZFgofRR01yWF2lFupnIhS05or6MWk=; b=sBISeSjp4BRd7RylOLQaDEteZ3HWGNUuJW7sEQAGLsMd//QrvxAsJWQIcTkKB80wjH 0kTFTmTfQzqBiC0zWOuaEqAyHN7Kye3G5I3XrXHHft+dxDYkvrQT83o64yqSuRgZkxyi 2gKzFrscly+l0hJCTJle3UcwWuQSnLJtH9IUg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=phfaW9JYpSwukAvNVfwTLE46cmx7BM0dNUwo912XQpgwq3G4bBS1XD5d8nrX4F7wKq EdrH/0KJvHnz+TtPUNiRaiYrVEDk3R9ue42dp+wNKG4n5ZWbMKiKspKlZBhV4mLrtXBz kqHZ6aLTZzQA7OSTVKEVmjXy/D6pfnKK4DxuY= Received: by 10.224.3.10 with SMTP id 10mr2234908qal.195.1279872593170; Fri, 23 Jul 2010 01:09:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.13.225 with HTTP; Fri, 23 Jul 2010 01:09:33 -0700 (PDT) In-Reply-To: References: From: Meadhbh Hamrick Date: Fri, 23 Jul 2010 01:09:33 -0700 Message-ID: To: Morgaine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: vwrap@ietf.org Subject: Re: [vwrap] Moving ahead with draft-ietf-vwrap-intro X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 08:09:37 -0000 kk. ossm. -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com On Fri, Jul 23, 2010 at 1:07 AM, Morgaine wrote: > I'm a firm supporter of David's position on multiple deployment models, a > wide range of which should be possible.=A0 Our specifications need to mak= e > that flexibility clear instead of hanging on to old language that has its > roots in the walled garden model with which we started. > > I'm also a firm supporter of the IETF's mission statement with regard to > interoperability and scalability, which again places upon us a certain du= ty > towards those goals in our documents. > > I'm trying to improve our protocols and specification on both those front= s. > > There is certainly nothing to fear.=A0 Denying interoperation will always= be > possible, and trivial to accomplish.=A0 Our task is to allow interoperati= on > for those who want it. > > > Morgaine. > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > On Thu, Jul 22, 2010 at 11:06 PM, Meadhbh Hamrick > wrote: >> >> in other words... let's not start a fight over whether your model is >> supported or not. if you write up some words that support the tourist >> model, but don't make the fixed grid impossible, i'm all for it. >> >> -cheers >> -meadhbh >> -- >> meadhbh hamrick * it's pronounced "maeve" >> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> >> >> >> On Thu, Jul 22, 2010 at 3:05 PM, Meadhbh Hamrick >> wrote: >> > morgaine! you're frightening me! >> > >> > i think we should definitely support the tourist model, but please >> > don't try to take out the bits that support fixed / locked down grids. >> > there are many of us who will be implementing this style of VW. >> > >> > -cheers >> > -meadhbh >> > -- >> > meadhbh hamrick * it's pronounced "maeve" >> > @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> > >> > >> > >> > On Thu, Jul 22, 2010 at 1:45 PM, Morgaine >> > wrote: >> >> Barry, I've been reviewing the Intro document for several days now, a= nd >> >> there are important issues there that will need a certain amount of >> >> change. >> >> I don't expect it to be very contentious (basically the old OGP >> >> worldview >> >> needs to be brought into line with what's already been discussed in t= he >> >> group), but I will need some more days of work on it next week. >> >> >> >> Hopefully it won't take me too long. >> >> >> >> >> >> Morgaine. >> >> >> >> >> >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> >> >> On Thu, Jul 22, 2010 at 5:13 PM, Meadhbh Hamrick >> >> wrote: >> >>> >> >>> i don't think there are any outstanding issues with the intro draft. >> >>> >> >>> -- >> >>> meadhbh hamrick * it's pronounced "maeve" >> >>> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com >> >>> >> >>> >> >>> >> >>> On Thu, Jul 22, 2010 at 9:05 AM, Barry Leiba >> >>> wrote: >> >>> > Since there's been no discussion, yet, about "Introduction and >> >>> > Goals" >> >>> > =A0 http://tools.ietf.org/html/draft-ietf-vwrap-intro >> >>> > ...we should consider moving ahead with it. =A0To that end: >> >>> > >> >>> > 1. Meadhbh, is there anything outstanding that you think needs to = be >> >>> > addressed? =A0Any specific input you need from the working group? >> >>> > >> >>> > 2. David, can you get the IPR statement on Meadhbh's original >> >>> > version >> >>> > =A0 https://datatracker.ietf.org/ipr/1294/ >> >>> > ...updated, if it's still applicable to the WG version? =A0If it's= not >> >>> > still applicable, we'd need you to tell us that. >> >>> > >> >>> > 3. Working group: please review the document and discuss any issue= s >> >>> > with it. =A0Joshua and I will also appreciate comments saying "I'v= e >> >>> > reviewed it, and it's ready to go." >> >>> > >> >>> > Barry, as chair >> >>> > _______________________________________________ >> >>> > vwrap mailing list >> >>> > vwrap@ietf.org >> >>> > https://www.ietf.org/mailman/listinfo/vwrap >> >>> > >> >>> _______________________________________________ >> >>> vwrap mailing list >> >>> vwrap@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/vwrap >> >> >> >> >> >> _______________________________________________ >> >> vwrap mailing list >> >> vwrap@ietf.org >> >> https://www.ietf.org/mailman/listinfo/vwrap >> >> >> >> >> > > > > _______________________________________________ > vwrap mailing list > vwrap@ietf.org > https://www.ietf.org/mailman/listinfo/vwrap > > From ohmeadhbh@gmail.com Fri Jul 23 11:20:21 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ABB43A67D1 for ; Fri, 23 Jul 2010 11:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.34 X-Spam-Level: X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[AWL=0.259, 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 TljrxeBuM73l for ; Fri, 23 Jul 2010 11:20:19 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id F0D163A6A68 for ; Fri, 23 Jul 2010 11:19:49 -0700 (PDT) Received: by gxk1 with SMTP id 1so271134gxk.31 for ; Fri, 23 Jul 2010 11:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=rEedgEtL5oXmi7fes6d701S6FG3uYEtTILZel4/rC8k=; b=iLvFBJKNaKbK/bOHWxrN74WgsHgcquHZNhLgnR653DChjdcWmrET7NVsyeIwGbeHED 5yHsBIXC0OJhg36KGXEQAZV3sRKWhpiLJE0eyKW8emX+d0YpgUNMuXjsrpvlEksX0UcY +2bubLRmYUzhoFKzbhz/kEwIor5zMpDFfsrZI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=n6xETOX4DlhSsnmh2dkEaPUHk0dx+982mDv+OMSCqnCkjNWTG74Jr9CveohYHtU/s2 ++CdtkKoT2tb/mBzsefhJmoMSh4OFqsR5cCWQ7tWwC9l90k1SsgJO68ydSQZV9FC4ygB PdKaTSH/lS0II3Rh82ivGRkCvc1H/qr4YTbrU= Received: by 10.150.237.14 with SMTP id k14mr6185009ybh.335.1279909207640; Fri, 23 Jul 2010 11:20:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.13.225 with HTTP; Fri, 23 Jul 2010 11:19:46 -0700 (PDT) From: Meadhbh Hamrick Date: Fri, 23 Jul 2010 11:19:46 -0700 Message-ID: To: vwrap@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [vwrap] truer words have never been spoken X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 18:20:21 -0000 thought this might be of interest to list members as we're building specs and implementations in parallel: was just pointed to this email from the public-html list at w3.org: http://lists.w3.org/Archives/Public/public-html/2010Jan/0107.html "Implementations and specifications have to do a delicate dance together. You don't want implementations to happen before the specification is finished, because people start depending on the details of implementations and that constrains the specification. However, you also don't want the specification to be finished before there are implementations and author experience with those implementations, because you need the feedback. There is unavoidable tension here, but we just have to muddle on through..." -cheers -meadhbh -- meadhbh hamrick * it's pronounced "maeve" @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com From barryleiba.mailing.lists@gmail.com Mon Jul 26 07:00:56 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86A703A69F8 for ; Mon, 26 Jul 2010 07:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.166, 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 5b7dehpb38JA for ; Mon, 26 Jul 2010 07:00:55 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 9DC913A691D for ; Mon, 26 Jul 2010 07:00:55 -0700 (PDT) Received: by pwj1 with SMTP id 1so62129pwj.31 for ; Mon, 26 Jul 2010 07:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to:date :message-id:subject:from:to:content-type; bh=qXDyIahkVWvXjV9/JAjMKuk+nxPQ4kXWGAGg4qdiilk=; b=KDtSelBIVArmFljHLV9hk32UowWsW183BlmwjppyqC4q7zmyeHHBJ2n7I+avFTglO8 9YjleoP45k/RODlIlq3Ez4rUI+d9vr0lT3YPa7rwZF5WpLeewKfZJYlcJjXv+PtM/SyI /jsni7/bfoJTmKmhU/hkaVAxo+v0/61exO8xo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=p65Ur/oTS+0/xHVGzxmRujI3UYzG4yyNDswjubZ3320XIaQ6czZVz+svxGHCYg+MoT lj/Tpc+isTqa+R1TcS6KVZ8TLqlbRVcbbxWogSdZ8y1q5o9U6krH+vOE1ZicY1BQqeGE SYTJMljhkxpY2gOxxUkvhnYBt/wnN+Z7E0+z4= MIME-Version: 1.0 Received: by 10.114.75.17 with SMTP id x17mr11490761waa.86.1280152876499; Mon, 26 Jul 2010 07:01:16 -0700 (PDT) Received: by 10.42.1.136 with HTTP; Mon, 26 Jul 2010 07:01:16 -0700 (PDT) Date: Mon, 26 Jul 2010 10:01:16 -0400 Message-ID: From: Barry Leiba To: vwrap@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [vwrap] draft-ietf-vwrap-type-system and RFC 2817 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 14:00:56 -0000 draft-ietf-vwrap-type-system-00 has a reference to RFC 2817, which we noticed in httpbis just now, when we talked about deprecating that RFC. The reference should be to RFC 2818. It, as well as the reference to RFC 2616, should probably be informational, not normative, at least as it's used now. So how about this?: OLD LLIDL describes abstract interfaces intended to be reified over HTTP [RFC2616] or HTTPS [RFC2817]. NEW LLIDL describes abstract interfaces intended to be reified over a protocol such as HTTP [RFC2616] or HTTPS [RFC2818]. ...and change and move the references. Barry, as participant From dzonatas@gmail.com Sat Jul 31 06:48:17 2010 Return-Path: X-Original-To: vwrap@core3.amsl.com Delivered-To: vwrap@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A84DD3A698E for ; Sat, 31 Jul 2010 06:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zPph-oZWqKLg for ; Sat, 31 Jul 2010 06:48:16 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 5F1AC3A6965 for ; Sat, 31 Jul 2010 06:48:16 -0700 (PDT) Received: by pvd12 with SMTP id 12so993407pvd.31 for ; Sat, 31 Jul 2010 06:48:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=sBpPeRW2T/U3umVQ7dXBXNq5Pp5jM2riKJ2xnqFOgRQ=; b=OF8E6HS4MfE/03pJEwy3O6ouNKGt0OhTDi6YJlPWcsYeCWW6e+ZVqONJsJoDVwrg0t dB+uS/v+4ujat/ceid627gGkCrgT2QUCeTBDZKDW1ZoyIo/TKtLbFZFm/Lc+N4HfJalJ s4opKTHVlItRavEPvUpaje0+UD17g1CY6nFmE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=fQoCQn/6uMq+ES9vfwJSIirhA1zN7S/c0Aw0pyaSNUxV+NPDphRIQBe9RXnCaM8/v7 v3khvvU8ZfPmI9bAzsyxtUnLL+h8klMXDLCNXhDh3Q992Ouh45UCtk7MjBpKFve1Ixra Sdus0qqqyiVEQjKwr9TmlErdrzSk3FrBHlRJU= Received: by 10.114.195.12 with SMTP id s12mr4040414waf.204.1280584121870; Sat, 31 Jul 2010 06:48:41 -0700 (PDT) Received: from [192.168.0.50] (adsl-68-124-103-250.dsl.scrm01.pacbell.net [68.124.103.250]) by mx.google.com with ESMTPS id k23sm6213624waf.5.2010.07.31.06.48.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 31 Jul 2010 06:48:41 -0700 (PDT) Message-ID: <4C542CAC.1090301@gmail.com> Date: Sat, 31 Jul 2010 07:01:16 -0700 From: Dzonatas Sol User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329) MIME-Version: 1.0 To: "vwrap@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [vwrap] Working Draft: SNOW-375 X-BeenThere: vwrap@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Virtual World Region Agent Protocol - IETF working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Jul 2010 13:48:18 -0000 Hi, SNOW-375 is at a point to feature freeze and to fill-in development on whats already included. Icesphere (C# based client to Snowglobe & Second Life) uses SNOW-375 as a ReST based API. This shares concepts with VWRAP. Currently writing the resource dictionary, but here is an excerpt of documentation just put together: Overview SNOW-375 is an API to the Snowglobe code base to query reflexive information that affects Avatar, Agent, Assets, Inventory, Gestures, and other states of the client as it interacts with the virtual world. In order to enable the widest range of devices and scripts to communicate with the client, the API is language-agnostic. The flexibility of client-side scripting is a significant feature of SNOW-375. SNOW-375 allows for a multi-headed client architecture instead of a single monolithic design. There are many possibilities to this besides client-side scripting, like augmented reality devices, gesture recognition devices, social networking, advanced heads-up displays, integrated desktop programs (desklets), joysticks, machinima tools, and many more. Multi-headed clients are also significant, yet its transport layer may be platform dependent. Read more: http://icyspherical.blogspot.com/2010/07/overview-snow-375-is-api-to-snowglobe.html -- --- https://twitter.com/Dzonatas_Sol --- Web Development, Software Engineering, Virtual Reality, Consultant