Re: [mmox] mmox Digest, Vol 1, Issue 113

"Meadhbh Hamrick (Infinity)" <infinity@lindenlab.com> Mon, 23 February 2009 21:54 UTC

Return-Path: <infinity@lindenlab.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 A543B28C20B for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 13:54:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.59
X-Spam-Level:
X-Spam-Status: No, score=-3.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzERu+fJ7lan for <mmox@core3.amsl.com>; Mon, 23 Feb 2009 13:54:11 -0800 (PST)
Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id BC61528C203 for <mmox@ietf.org>; Mon, 23 Feb 2009 13:54:11 -0800 (PST)
Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id 5139D3DBC44F; Mon, 23 Feb 2009 13:54:30 -0800 (PST)
Message-Id: <9EF1FD3F-6E1B-471B-B11B-169CA6CFAB7C@lindenlab.com>
From: "Meadhbh Hamrick (Infinity)" <infinity@lindenlab.com>
To: Jon Watte <jwatte@gmail.com>
In-Reply-To: <49A31A11.2000503@gmail.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Mon, 23 Feb 2009 13:54:30 -0800
References: <20090223.155250.2225.0@webmail24.vgs.untd.com><a768bcd90902231319o568d866bx39f1f91cc1f7a31c@mail.gmail.com> <49A31A11.2000503@gmail.com>
X-Mailer: Apple Mail (2.930.3)
Cc: mmox@ietf.org, "dyerbrookme@juno.com" <dyerbrookme@juno.com>
Subject: Re: [mmox] mmox Digest, Vol 1, Issue 113
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 21:54:12 -0000

but i believe the sense of the comment was that the end user (distinct  
from the person who administers the service) is not allowed to upload  
arbitrary content.

my understanding of both OLIVE and there.com is that they both do not  
allow arbitrary content upload, but instead require someone other than  
the content creator approve (and transfer) the content.

but... i could be wrong.

On Feb 23, 2009, at 1:50 PM, Jon Watte wrote:

> Dan Olivares wrote:
>> "In the There.com/Forterra context, customer content is cleared
>> through a centralized clearing house and must be approved by the
>> company before it can be uploaded; customers are in a subordinate
>>
>
> Just to be clear: There.com (operated by Makena Technologies) and  
> OLIVE (sold by Forterra Systems) are different products, with very  
> different customers and very different processes. There.com has a  
> central clearinghouse. Forterra Systems does not -- each customer of  
> the OLIVE platform decides how and what content goes into their  
> installation.
>
> The There.com model is "we provide a PG-13 safe environment with  
> some degree of content protection, and we implement it through a  
> content review system" (and now the iPhone store does the same thing).
>
> The OLIVE model is "let the customer decide, although we can help  
> you with that if you need help."
>
> Sincerely,
>
> jw
>
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox