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

[Kajikawa Jeremy <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmox