Re: [mmox] mmox Digest, Vol 1, Issue 111
Kajikawa Jeremy <belxjander@gmail.com> Tue, 24 February 2009 02:29 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 08E0D28C27F for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 18:29:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.635
X-Spam-Level:
X-Spam-Status: No, score=-1.635 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396]
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 Dzm4gh52+UZ9 for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 18:29:52 -0800 (PST)
Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by core3.amsl.com (Postfix) with ESMTP id AA59E28C27E for <mmox@ietf.org>; Mon, 23 Feb 2009 18:29:52 -0800 (PST)
Received: by wa-out-1112.google.com with SMTP id m33so1176373wag.5 for <mmox@ietf.org>; Mon, 23 Feb 2009 18:30:10 -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=6WztGqadDnWEil/XdCYxBgs95JgDUG45yebji7X9lk0=; b=EdwOQykeoQRVuemiKmae5XxZCp7q6bX8Bm/4SNQRYwfxJhXVwhSDZVsNMPr9CnaLCF vAq6paRsyP39ElCAgOgGBZ10y1f/dPGyZOBqdh0dM78oaIv/xCLGA2VfzRTAyMclGZ7V ykaK9YNEFqo39n/7JG6VvqqXAzRmpISgqi3BM=
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=Gx3wp9L/yzgNlLjOE/+UbUZtuGeEFUVao/b3aVkg4ZfucjJmfZ03Mgc7RQ5PxxvQS4 eUOAUzAcO1XuQ+T6cAOnUoiEsWpn7nNQX9ViABKpFVHhKScyYCv7s2JAACBhZGGErC5m iiA0x3GBJZcR1BpkXj5lW2y7SsVZTX96uRL7w=
Received: by 10.115.110.6 with SMTP id n6mr1920306wam.227.1235442610669; Mon, 23 Feb 2009 18:30:10 -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 g14sm6723528rvb.0.2009.02.23.18.30.08 (version=SSLv3 cipher=RC4-MD5); Mon, 23 Feb 2009 18:30:10 -0800 (PST)
From: Kajikawa Jeremy <belxjander@gmail.com>
To: "mmox@ietf.org" <mmox@ietf.org>
In-Reply-To: <49A30FE2.1010801@gmail.com>
References: <20090223.084454.24252.0@webmail09.vgs.untd.com> <53cd6c2e0902230613y6e86f16fyaa841a08db4b86d1@mail.gmail.com> <49A30FE2.1010801@gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-Zv0Nqg59iuJqKYy/S0Wo"
Date: Tue, 24 Feb 2009 02:24:47 +0000
Message-Id: <1235442287.6608.119.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1
Subject: Re: [mmox] mmox Digest, Vol 1, Issue 111
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: Tue, 24 Feb 2009 02:29:54 -0000
and this is why I am wanting any "object" (AV included!) to be a block of extensible attributes to allow provision of DRM and also ignoring DRM sections where the VW in question chooses to do so... the only "common denominator" would be a mandate to not "mangle" the object and attempt to "strip" the DRM or otherwise damage the object data... I recommend for an object to be able to grow but not pruned unless killed. This would be part of the reason why Im wanting to seperate the objects from Identity... That way someone like myself can have a "common name" but have each VW visited either be a re-usable or one-time account access... I might access "OSgrid.org" and show up as a Caveman or Star Trek engineer there and then teleport to "Guild Wars" or another MMORPG... If I want to *visit* WoW and learn about it... I may do that and be allowed a temporary account there with a single-session limitation with lack of some interaction? When making the jump to WoW or GW I would be entering a Swords&Sorcery arena... coming from SecondLife or OSgrid wearing a Star Trek uniform is definitely out... along with any transfer of content... I would *-need* to make a new AV and select to whether I am to become a member or I am only visiting... Im pursuing this based on my knowledge of existing specifications and also my perspective as an end-user on some existing MMO systems. I also dont expect to go beyond Identity being transferable to non-compatible VWs. Changing from SecondLife to OpenSIM they have a compatible architecture... and I would think I would keep only what I was wearing or carrying attached. is there *any* valid reason to go beyond this?... the *only* use cases I am understanding would entail definition of Identity and some mechanism for a chain-of-credentials that the servers can use for Identity and making sure the correct account is used for each login along with a "compatible systems" transfer of AV objects and the vehicle carrying it only when the user chooses to do this. If the User is transferring to a new VW grid or system, and has an existing account, then I would prompt the user with a request to change their AV from the originating systems AV representative to the new systems representative. This would keep the walled Garden... and the only other part of this standard would then become the connection of commerce... Do we permit the SecondLife "Linden" play-money to be valid play-money in OSgrid? do we permit an in-game currency from VW-A to be converted for currency in VW-B? We can define an optional mechanism for supporting such actions (expanding commerce and the area with which content may become served...) as that would keep the walled garden but also allow *wall-less* areas outside the gardens "to grow wild and free" as the dictates of the users permit. THAT is the model with which I am currently imagining as practical AND inside the scope of the MMOX charter (and it also provides a benefit to commercial entities) The value-add for cross-connection is not in an immediate effect... its initially a drain of resources for making it happen... but the value-add result is more users have more access, opening your doors to more foot-traffic... VW foot traffic may be mostly one-time-shoppers... but a LOT of people do return to where they get good service... and time spent making your service available does this not pay back in returns by having loyal customers? personally Im ignorant of the details and this is as simple-minded as I am... Does the above approach work for you? since you can mark an "attribute" for your content objects as being "allowed outside the garden"(GPL/CC) or "this garden only"(*-EULA/Commercial License blah...) Anyway...Im going back to constructing my own VW implimentation toward that vision and I wish everyone else luck with trying to enforce their own opinions on others... I invite you all to only consider that vision and explain to me where you see it having holes or lacking expansion? since I am deliberately leaving whole swathes of items for extensions to the spec, VW Federated Identity / VW Currency Exchange / VW Object Exchange I propose that we define towards compatible systems becoming interlinked first and work out a means of having additional non-compatible systems interconnect in later drafts... We dont need to solve everything now...we jujst need to get the snowball started down the hill and all the bullshit about DRM/commerce and the rest needs a better hearing... On Mon, 2009-02-23 at 13:06 -0800, Jon Watte wrote: > Jesrad wrote: > > I actually wrote that mandating the implementation of DRM on top of > > any permission/copyright metadata transmission mechanism would severly > > reduce the number of grid systems that comply with the protocol. > > > > Note that it would be totally possible for someone to come up with a DRM > scheme, that mandates that content create /under that DRM scheme/ only > be transferred to other trusted implementors of that scheme. That would > mean that, if the content was created on a compliant system, and > properly marked, it could not "escape" into non-DRM systems. I think > that enabling this within the standard is important. > > A world can then compete for attention, by implementing and adhering to > some popular scheme. For example, if creators feel most comfortable with > "Microsoft VW Content DRM" or "MacroMedia ContentSafe(tm)," they could > make sure to create their content in a world certified by one of those > providers, and mark the object as not transferable outside those > domains. Part of the certification would then be to make sure that such > marks are actually adhered to. This neatly splits the interoperability > protocol into the interoperability part, which is free, open, and allows > OpenSim or LeftistWorld to be as open as they want, and the > DRM/enforcement part, which allows the concerned content creators to > stay as locked-up as they want within RightistWorld. > > Sincerely, > > jw > > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox
- 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