Re: [mmox] the arguments are sidelining people...
Kajikawa Jeremy <belxjander@gmail.com> Mon, 23 February 2009 15:16 UTC
Return-Path: <belxjander@gmail.com>
X-Original-To: mmox@core3.amsl.com
Delivered-To: mmox@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DD4F3A6A92 for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 07:16:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.28
X-Spam-Level:
X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.319, 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 bE1YPnWYzQPc for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 07:16:08 -0800 (PST)
Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by core3.amsl.com (Postfix) with ESMTP id 7D43C3A6864 for <mmox@ietf.org>; Mon, 23 Feb 2009 07:16:08 -0800 (PST)
Received: by wa-out-1112.google.com with SMTP id m33so1044489wag.5 for <mmox@ietf.org>; Mon, 23 Feb 2009 07:16:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:disposition-notification-to:content-type:date:message-id :mime-version:x-mailer; bh=HJyOTZfSNFLw6agJLXWY6dOW1stxGIbF4T2yQhf2tog=; b=mJd08gNmps9Sv/BQ8bVrpm2F6c7SkDpeen6zwsZiv2LgNBSygTl1twS/9EhTAG5MMG sht81zmGbct49Uvi/Q54AK2qCK6ugCJpLkX6Pz3qKLtg5Vu+5kfrfiDdxDu/gWVIqgj/ V3X+RWx0mAPLJun3lS5KERmL91f/akL0+pWXI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:disposition-notification-to :content-type:date:message-id:mime-version:x-mailer; b=LqtTOP73FkfPGcrwvcQvd3K/5+3XGUhXDrQ/pq6PCCp8z0m9GcB8jtAEMJKpi/PEhg OlhfEyLV3nYGP1vsj3roqg7hepB3pv/ul74n5Hrjc7+y2YBCxRoFDiOR08mYk0rsWX+o Cm0iPYKpSQMc0iXPPQCK4YVvaDFYz5arWdU5g=
Received: by 10.114.131.11 with SMTP id e11mr1713069wad.75.1235402185334; Mon, 23 Feb 2009 07:16:25 -0800 (PST)
Received: from ?10.2.1.3? (p1012-ipbfp305tottori.tottori.ocn.ne.jp [114.155.20.12]) by mx.google.com with ESMTPS id g14sm6261997rvb.0.2009.02.23.07.16.23 (version=SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 07:16:24 -0800 (PST)
From: Kajikawa Jeremy <belxjander@gmail.com>
To: "mmox@ietf.org" <mmox@ietf.org>
In-Reply-To: <20090223.084454.24252.0@webmail09.vgs.untd.com>
References: <20090223.084454.24252.0@webmail09.vgs.untd.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-VFjujjC6Pv2K5kf8swlP"
Date: Mon, 23 Feb 2009 15:11:04 +0000
Message-Id: <1235401864.6608.63.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1
Subject: Re: [mmox] the arguments are sidelining people...
X-BeenThere: mmox@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Massively Multi-participant Online Games and Applications <mmox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmox>
List-Post: <mailto:mmox@ietf.org>
List-Help: <mailto:mmox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Feb 2009 15:16:09 -0000
currently I am seeing argument with regards the following Which virtual world system is more .... <<< CAN WE QUIT THE PISSING CONTEST? to DRM or not to DRM... allow encryption == yes, mandate it, hell no... I will not mandate screwing over implimentation with damaged and suspicious black boxed code for my own implimentations and any form of DRM is easily subverted where a "trusted" party performs the subversion of its core function. reference = rc4 and other cipher algorythms having TLS support and NULL encryption, this is perfectly valid and provides a hole regardless of system. Either the content creators wake up and accept that each Virtual World IS different along with that eventually the web itself will become 3D and people are going to need their services a hell of a lot more for throwaway or personalized items. Each "system" may be as diverse as a "Star Trek" simulation and a "Battle of Troy" or become as diverse as the "Star Wars" and other Role-play systems backgrounds... Personally I can see people walking around various VWs as both Medievil and Technology-expanded variants... will they meet? yes... where? in any "open" or otherwise "public" virtual world with an interop agreement... My own personal view of virtual worlds has been affected by a LOT of my reading material and I dont expect anyone to actually believe how fast I read... since I can read somewhere in the order of 1-2 pages per minute without exaggeration at all... Ive also looked through a good dozen or more RPG systems and see something of a "Rifts" crossed with "Stargate" crossed with "contemporary now" occuring... a LOT of the VWs are *escapes* from the real world and need to keep that function, walking into a "Swords and Sorcery" simulation from a Tech sim would be a social no-no so I am asking about making options here... I may be coming across as harsh with the following but this is from the perspective of a potential developer on any of the VWs or a potential rival... 1: Identity - This is the User Account and what access is required? 2: Representation - This is the Avatar or focus object... 3: Connection - What form of connectivity occurs? 4: Transport - Is anything actually needing to be transferred cross-system? if so...what? 5: serialization of data - this needs to be agnostic and readily available... For the above I submit the following as usable... 1: Identity I submit use of OpenID and OAuth for current mechanisms and also recommend requiring some kind of SSL or TLS. 2: Representation I submit this to be *optional*... First access to any system - provision of a "TEMPORARY" account (garbage collect on expiry or mark "free" for re-use are choices here). 3: Connection I see this as actually bogus, only the Identity requires Connection and Transport of secure data, anything of the AV transferred would be usable for "common server" data, 4: Transport as a subsection of 3 and requiring 5: Serialization. llsd is a form of XML for my reading and it appears to conform to a file format more than XML does... make the tags for the angle brackets relevant. I submit the following to allow mixed human readable AND machine readable data content for use of mixed systems... <object label="some name"> <attribute name="UUID">0000-0000-0000-0000-0010</> <attribute name="asset-0">0000-0000-0000-0000-1000</> <attribute name="asset-1">0000-0000-0000-0000-1001</> <attribute name="asset-2">0000-0000-0000-0000-1002</> <attribute name="asset-3">0000-0000-0000-0000-1003</> <attribute name="asset-4">0000-0000-0000-0000-1004</> <attribute name="prim">encoding:sha1:encodeddatastring</> <attribute name="mesh">encoding:sha1:encodeddatastring</> </> The above is submitted as an example for what I have in mind... extensible attributes. attributes may be added or edited by the original author or as technical limitations can permit legally.
- Re: [mmox] mmox Digest, Vol 1, Issue 111 dyerbrookme@juno.com
- Re: [mmox] mmox Digest, Vol 1, Issue 111 dyerbrookme@juno.com
- Re: [mmox] mmox Digest, Vol 1, Issue 111 Dan Olivares
- Re: [mmox] mmox Digest, Vol 1, Issue 111 Jesrad
- Re: [mmox] mmox Digest, Vol 1, Issue 111 dyerbrookme@juno.com
- Re: [mmox] mmox Digest, Vol 1, Issue 111 Jesrad
- Re: [mmox] mmox Digest, Vol 1, Issue 111 dyerbrookme@juno.com
- Re: [mmox] the arguments are sidelining people... Kajikawa Jeremy
- Re: [mmox] mmox Digest, Vol 1, Issue 111 Gareth Nelson
- Re: [mmox] mmox Digest, Vol 1, Issue 111 dyerbrookme@juno.com
- Re: [mmox] mmox Digest, Vol 1, Issue 111 Dan Olivares
- Re: [mmox] mmox Digest, Vol 1, Issue 111 Dan Olivares
- Re: [mmox] mmox Digest, Vol 1, Issue 111 dyerbrookme@juno.com
- Re: [mmox] mmox Digest, Vol 1, Issue 111 Dan Olivares
- Re: [mmox] mmox Digest, Vol 1, Issue 111 Jon Watte
- Re: [mmox] mmox Digest, Vol 1, Issue 111 Jesrad
- Re: [mmox] mmox Digest, Vol 1, Issue 111 Kajikawa Jeremy
- Re: [mmox] mmox Digest, Vol 1, Issue 111 dyerbrookme@juno.com
- Re: [mmox] mmox Digest, Vol 1, Issue 111 Dan Olivares
- Re: [mmox] mmox Digest, Vol 1, Issue 111 Dan Olivares
- Re: [mmox] mmox Digest, Vol 1, Issue 111 Kajikawa Jeremy