Subject: Re: [mmox] mmox Digest, Vol 1, Issue 45

From: "[email-masked]" <[email-masked]>
Date: Fri, 20 Feb 2009 18:48:55 GMT

>However, we do have customers who are asking for interoperability, and are prepared to pay for it. That's why I'm here. If you're thinking of interoperability only in the sense of the Second Life grid, using Second Life protocols, serving Second Life customers, I don't think that's something the IETF should care much about.

Jon, in your other posts you seem to make a hard distinction between "business users" which are large corporations, and other users which you seem to imply have no money, or only small wallets to buy dresses. But collectively, the users of Second Life, including all the content-creators and merchants, represent *as powerful a financial force* for a platform provider as their original venture capitalists and as their best big enterprise customers. In Second Life, those small businesses inworld scorned by some as "socializers" collectively pay more of the tier (server maintenance fees) than any other category of customer, and therefore make up the provider's bottom line. 

The mass of *these* users and their tier have not spoken in favour of interoperability as the issue hasn't even been put to them, nor the implications outlined. You as Forterra may have big clients who care about interoperability, but they have other ways to protect 
their content (firewalls, centralized content clearance, teams of lawyers) and have different motivations for "interoperability" than the average world user.

>As I said, that's up to each platform vendor. The important thing is to enable the metadata to travel with the content, and to empower the 
sending side to make determinations about:
a) who they interoperate with
b) what specific content will and won't interoperate based on local policy. How Linden Labs decides to apply policy to content created by Linden Lab users is totally separate from how the interoperability specification should treat interoperable content, and should not be subject of discussion on this list (just like I won't discuss my customer specifics on this list).

You're assuming that Linden Lab simply won't let pass through its gates an object that is not marked for transfer. But Linden Lab's entire world has been reverse-engineered in OpenSim! (yes, based on the reverse-engineering of libsecondlife originally). And Linden 
Lab already has stood by while Second Inventory, a system that enables copying all your inventory and holding it offline, has functioned, with people then re-uploading the content to the OpenSim reverse-engineered platform. There, we are to expect that the permissions will "hold" but that grid has no permissions and a decided copyleftist outlook on these matters. Already copying of entire islands and builds, not to mention individual content like trees and clothing, are sprouting up all over the OpenSim grids, which have spawned dozens of sub-grids. This is not some theoretical matter. SI says they only enable downloading of inventory for which you have permissions, 
yet the uploading into the next grid takes place in an environment with no c/m/d.

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 role. In Second Life, content-makers and scripters and animators appear as equals to the platform provider when it comes to content generation, and in fact have produced the lion's share of the world's content, unlike other worlds where the platform providers make all the content. Therefore this isn't just some "customer specifics" that has to be routed through the company, as you prefer.

If Linden Lab and its AWG members (including IBM) do not wish to defend c/m/d going forward into interoperability, then in a sense, they've declared on behalf of the extremist position to remove it inworld:
http://jira.secondlife.com/browse/VWR-2909

Could the members of this list comment on their dual positions, supporting c/m/d tacitly inworld in SL, but not for the Metaverse?

>I think you have misunderstood my proposal. My proposal is that the copy semantics should be explicitly part of the metadata, and should be enforced on the sending side, according to the EULA of that sending 
side. If an object is marked "do not copy" then the sending side won't 
send it, and the object won't interoperate. Exactly how each producer 
implements that is beside the scope of any standard, though. For 
example, if Linden Labs decides to apply a default policy of 
"interoperable" to all existing content, or to apply a default policy of "not interoperable," is entirely outside of the scope of any standard or standards discussion. It's a Linden-specific matter.

That's what *you* say as you theorize it; it's not what Linden Lab has said. Linden Lab has been asked by users whether a flag can be placed on objects indicating a creator's wishes to let an object port to another grid or not, and has remained silent on that prospect:

http://jira.secondlife.com/browse/MISC-1272

A further quest for clarification also has no answer:

http://jira.secondlife.com/browse/MISC-1277

Let you or Dan Olivares think that somehow the 30-40 people voting on this "doesn't represent anything" (something that isn't an avowed generic concern of IETF in its own governance regime), look at other JIRAs such as a popular one calling for action against texture theft to understand the magnitide of the concern about this by people who 
make real money, not play money:
http://jira.secondlife.com/browse/SVC-676 (1003 votes)

>In fact, I am arguing that we should enable exactly what you're 
describing! I don't understand how you belive I'm not.

I think it's very simple: you have to clarify whether you are for putting copy/mod/transfer permissions on objects or not.

In There.com, this issue is solved by not having such things appear on the object at all, because the solution is to have a centralized clearing house for content. Private customers on private grids that Forterra handles don't have this issue because they have firewalls and military clearances and such. But we're in the open Metaverse.

So the issue is how, in an open world, where user content is generated on demand, going forward into interoperability with other grids, these permissions once established by Linden Lab can be respected -- and respected not by telling everybody to call their lawyers, file a DMCA, or put in a notecard with a CC license, but implemented with a 
technical solution, even an imperfect one.

It depends on whether you mean c/m/d in the metadata, and whether you are putting the onus for prevention of non-permed content to go to other grids on the original grid operator. What if the original sending grid operator doesn't care, or is hacked, then are 
you not willing to put any responsibility on the receiving grid? 

____________________________________________________________
Free information - Scholarships for  college, university or tech school. Click now!
http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTEakCWUCwpioOh44oxV2Z8dg6el4A6DgYwceHqeIAvEH5WQdSgno0/

---

From: Charles Krinke <[email-masked]>
Date: Fri, 20 Feb 2009 11:11:15 -0800 (PST)

Dear David and Meadhbh:

I'm confused about some of the posts from email addresses that are either unsigned or from pseudonyms.

It seems entirely reasonable to me that real names be used in this mailing list to avoid wasting all our time and so that we know who whe are speaking with.

Is there some way in an IETF mailing list or by peer pressure to get this to a more businesslike stage?

Charles Krinke

---

From: "Robert Gehorsam" <[email-masked]>
Date: Fri, 20 Feb 2009 11:14:20 -0800

>> 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 role.

This assertion contains an incorrect assumption.  It is true that in the
There service, content goes through a central clearing house.

Let's be clear:  Forterra is a different company, with a substantially
different technology, different market, different business model and
different operation than Makena, the company that operates There.  The
common thread is the underlying IP which describes the technical
architecture, but the actual code base is now quite different.

Forterra does not own the servers on which its customers develop and
operate their services and applications.  Each customer (and its
authorized end-users) are free to develop and deploy any content they
want, and we play no role in that, even if a customer wants us to host
their servers.  We're happy to provide studio services to help people
develop content, or provide pre-existing content packs for them as well,
but that's just at customer request..  Same is true for functionality.
In Forterra's model -- customers and end-users are actually in the
drivers seat.

Hope this helps.

Robert

-- by way of introduction, I'm part of the management of Forterra.  I'm
not a programmer or technologist, work mostly on the business and
strategy side.  But the interoperability issue has been central to what
we see as the evolution of vw's, so I'm happy to follow the conversation
and contribute wherever it makes sense.

Robert Gehorsam
President
Forterra Systems
48 Wall Street, 11th floor | New York, NY |10005
212 918 4564 (o) | 212 918 4937 (f) | 917 817 8107 (m)
[email-masked]
www.forterrainc.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, February 20, 2009 1:49 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mmox] mmox Digest, Vol 1, Issue 45

>However, we do have customers who are asking for interoperability, and
are prepared to pay for it. That's why I'm here. If you're thinking of
interoperability only in the sense of the Second Life grid, using Second
Life protocols, serving Second Life customers, I don't think that's
something the IETF should care much about.

Jon, in your other posts you seem to make a hard distinction between
"business users" which are large corporations, and other users which you
seem to imply have no money, or only small wallets to buy dresses. But
collectively, the users of Second Life, including all the
content-creators and merchants, represent *as powerful a financial
force* for a platform provider as their original venture capitalists and
as their best big enterprise customers. In Second Life, those small
businesses inworld scorned by some as "socializers" collectively pay
more of the tier (server maintenance fees) than any other category of
customer, and therefore make up the provider's bottom line. 

The mass of *these* users and their tier have not spoken in favour of
interoperability as the issue hasn't even been put to them, nor the
implications outlined. You as Forterra may have big clients who care
about interoperability, but they have other ways to protect their
content (firewalls, centralized content clearance, teams of lawyers) and
have different motivations for "interoperability" than the average world
user.

>As I said, that's up to each platform vendor. The important thing is to

>enable the metadata to travel with the content, and to empower the
sending side to make determinations about:
a) who they interoperate with
b) what specific content will and won't interoperate based on local
policy. How Linden Labs decides to apply policy to content created by
Linden Lab users is totally separate from how the interoperability
specification should treat interoperable content, and should not be
subject of discussion on this list (just like I won't discuss my
customer specifics on this list).

You're assuming that Linden Lab simply won't let pass through its gates
an object that is not marked for transfer. But Linden Lab's entire world
has been reverse-engineered in OpenSim! (yes, based on the
reverse-engineering of libsecondlife originally). And Linden Lab already
has stood by while Second Inventory, a system that enables copying all
your inventory and holding it offline, has functioned, with people then
re-uploading the content to the OpenSim reverse-engineered platform.
There, we are to expect that the permissions will "hold" but that grid
has no permissions and a decided copyleftist outlook on these matters.
Already copying of entire islands and builds, not to mention individual
content like trees and clothing, are sprouting up all over the OpenSim
grids, which have spawned dozens of sub-grids. This is not some
theoretical matter. SI says they only enable downloading of inventory
for which you have permissions, yet the uploading into the next grid
takes place in an environment with no c/m/d.

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 role. In Second Life,
content-makers and scripters and animators appear as equals to the
platform provider when it comes to content generation, and in fact have
produced the lion's share of the world's content, unlike other worlds
where the platform providers make all the content. Therefore this isn't
just some "customer specifics" that has to be routed through the
company, as you prefer.

If Linden Lab and its AWG members (including IBM) do not wish to defend
c/m/d going forward into interoperability, then in a sense, they've
declared on behalf of the extremist position to remove it inworld:
http://jira.secondlife.com/browse/VWR-2909

Could the members of this list comment on their dual positions,
supporting c/m/d tacitly inworld in SL, but not for the Metaverse?

>I think you have misunderstood my proposal. My proposal is that the 
>copy semantics should be explicitly part of the metadata, and should be

>enforced on the sending side, according to the EULA of that sending
side. If an object is marked "do not copy" then the sending side won't
send it, and the object won't interoperate. Exactly how each producer
implements that is beside the scope of any standard, though. For
example, if Linden Labs decides to apply a default policy of
"interoperable" to all existing content, or to apply a default policy of
"not interoperable," is entirely outside of the scope of any standard or
standards discussion. It's a Linden-specific matter.

That's what *you* say as you theorize it; it's not what Linden Lab has
said. Linden Lab has been asked by users whether a flag can be placed on
objects indicating a creator's wishes to let an object port to another
grid or not, and has remained silent on that prospect:

Let you or Dan Olivares think that somehow the 30-40 people voting on
this "doesn't represent anything" (something that isn't an avowed
generic concern of IETF in its own governance regime), look at other
JIRAs such as a popular one calling for action against texture theft to
understand the magnitide of the concern about this by people who make
real money, not play money:
http://jira.secondlife.com/browse/SVC-676 (1003 votes)

I think it's very simple: you have to clarify whether you are for
putting copy/mod/transfer permissions on objects or not.

In There.com, this issue is solved by not having such things appear on
the object at all, because the solution is to have a centralized
clearing house for content. Private customers on private grids that
Forterra handles don't have this issue because they have firewalls and
military clearances and such. But we're in the open Metaverse.

So the issue is how, in an open world, where user content is generated
on demand, going forward into interoperability with other grids, these
permissions once established by Linden Lab can be respected -- and
respected not by telling everybody to call their lawyers, file a DMCA,
or put in a notecard with a CC license, but implemented with a 
technical solution, even an imperfect one.

It depends on whether you mean c/m/d in the metadata, and whether you
are putting the onus for prevention of non-permed content to go to other
grids on the original grid operator. What if the original sending grid
operator doesn't care, or is hacked, then are 
you not willing to put any responsibility on the receiving grid? 

____________________________________________________________
Free information - Scholarships for  college, university or tech school.
Click now!
http://thirdpartyoffers.juno.com/TGL2141/fc/BLSrjpTEakCWUCwpioOh44oxV2Z8
dg6el4A6DgYwceHqeIAvEH5WQdSgno0/
_______________________________________________
mmox mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmox

---

From: "Robert Gehorsam" <[email-masked]>
Date: Fri, 20 Feb 2009 11:25:57 -0800

Charles,
 
I agree.  
 
I just use my real name anyway, real world and online (except in mmogs
or SL where i can't.)
 
Robert Gehorsam

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Charles Krinke
Sent: Friday, February 20, 2009 2:11 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [mmox] Real Names

Dear David and Meadhbh:

I'm confused about some of the posts from email addresses that are
either unsigned or from pseudonyms.

It seems entirely reasonable to me that real names be used in this
mailing list to avoid wasting all our time and so that we know who whe
are speaking with.

Is there some way in an IETF mailing list or by peer pressure to get
this to a more businesslike stage?

Charles Krinke

---

From: "Meadhbh Hamrick (Infinity)" <[email-masked]>
Date: Fri, 20 Feb 2009 11:31:22 -0800

word from our IETF superiors is pseudonymous participation in the  
mailing list is acceptable.

though it's worth reminding people that pseudonymity does not shield  
list members or their sponsoring organizations from the IPR disclosure  
requirements.

also... IETF policy is that  internet drafts must be submitted using  
an authors legal name.

in terms of peer pressure? well... there's nothing to keep you from  
trying. historically, the IETF and the AWG seem to have a "more  
relaxed" working style than other groups i've seen.

-cheers
-meadhbh

On Feb 20, 2009, at 11:11 AM, Charles Krinke wrote:

> mailing list to avoid wasting all our time and so that we know who  
> whe are speaking with.
>

---

From: David W Levine <[email-masked]>
Date: Fri, 20 Feb 2009 14:33:30 -0500

Well, I actually asked this one directly. People are free to do what they 
like, tho, every utterance is assumed to be made by the underlying human 
in the context of the
"note well" constraints http://www.ietf.org/NOTEWELL.html  In 
particular,the NOTEWELL brings attention to :
http://www.ietf.org/rfc/rfc5378.txt  http://www.ietf.org/rfc/rfc3979.txt 
and the bug fix update in http://www.ietf.org/rfc/rfc4879.txt 

My clear example, has been to sign everything with both names... 

- David W. Levine
~ Zha Ewry (ISL) 

Charles Krinke <[email-masked]> 
Sent by: [email-masked]
02/20/2009 02:11 PM

To
"[email-masked]" <[email-masked]>, [email-masked]
cc
[email-masked], [email-masked]
Subject
[mmox] Real Names

Dear David and Meadhbh:

I'm confused about some of the posts from email addresses that are either 
unsigned or from pseudonyms.

It seems entirely reasonable to me that real names be used in this mailing 
list to avoid wasting all our time and so that we know who whe are 
speaking with.

Is there some way in an IETF mailing list or by peer pressure to get this 
to a more businesslike stage?

Charles Krinke_______________________________________________
mmox mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmox

---

From: Jon Watte <[email-masked]>
Date: Fri, 20 Feb 2009 11:48:42 -0800

Charles,

I would support a "real names only" policy.

I think the businesslike stage will happen if a determination of who 
actually has a business interest in interoperability is made. I don't 
know what the IETF rule on "observers" are -- parties who have an 
interest, but don't actually have a business directly involved in 
implementing the technology under consideration.

Sincerely,

jw

---

From: Ann Otoole <[email-masked]>
Date: Fri, 20 Feb 2009 12:09:18 -0800 (PST)

This is not about your meeting rooms Jon. You are clearly trying to shove Second Life out of the way and thus Forterra needs to be excluded from the outset.

I move we remove corporations from the process that have blatantly declared a pure greed motivation as Jon/Forterra has already done.

________________________________
From: Jon Watte <[email-masked]>
To: Charles Krinke <[email-masked]>
Cc: [email-masked]; "[email-masked]" <[email-masked]>
Sent: Friday, February 20, 2009 2:48:42 PM
Subject: Re: [mmox] Real Names

Charles,

I think the businesslike stage will happen if a determination of who actually has a business interest in interoperability is made. I don't know what the IETF rule on "observers" are -- parties who have an interest, but don't actually have a business directly involved in implementing the technology under consideration.

Sincerely,

jw