Re: [mmox] Permissions

[Kajikawa Jeremy <[e-mail]>]

I had a very interesting chat about this with Gareth...

and this is what I came up with... based off existing Email and
FileFormat styles...

Im going to tag this for style within this message...

anything in <> is to be machine readable sections,
anything encoded within a tagged item as "<...>encoded-data</...>"
 is to be human OR machine readable (Im not defining that here).
and I will be marking commentary below this point with the C++ comment
prefix "//"

<OBJECT 0xDEADBEEF>
  // Object verification starts here
  <ATTR label="name">My Custom AV Crossgrid Mohawk</ATTR>
  <ATTR label="license">MIT</ATTR> // human readable
  <ATTR label="pgp-sign">...</ATTR>
  <ATTR label="copy"></ATTR>
  <ATTR label="exportable"></ATTR>
  <ATTR label="resale"></ATTR>
  <ATTR label="UUID">0000-0000-0000-0000-0001</ATTR>
  <ATTR label="prim">...</ATTR>
  <ATTR label="mesh">...</ATTR>
  // Object verifies to here
</OBJECT 0xDEADBEEF>

// Processing concepts...

any "object" as described above will have mixed attributes when
export/imported
 across systems,  it may *gain* attributes but transfer back to the
originating system
 will include an "update-check" mechanism and notification of author
when a tampered
 item is detected...

Yes it breaks any "complex" down into bare primitive parts for various
systems,
  and also translates into "asset+inventory" functions of SL being
merged when out
  of that ecosystem along with trusted transfer mechanisms being used
for adding
  attributes where the author permits or the author can be specific and
use system
  permission markers on multiple systems where editing becomes
available.

This does have an enabling feature in that an incomplete object can be
invalidated
  at point of transfer where limitation of connection makes enforcement
occur in
  similar to a fashion of international travel.
  (you are crossing a great divide of some kind with the object)...

The above is to be defined as an inflexible bottom layer (physical
format)
  similar to the "layered transport" mechanisms already in use...
  recognition and use of any particular attributes by human or machine
processes
  is to be done as a seperate layer on top of this "formatted"
datastream...

This allows for encoding to a file OR encoding for transfer across the
network,
  either whole or not at all (the encoding needs to have a complete
transfer)... 

anyone who does make a "damaged" system will have it as a compromised
  server,  not as client system for any particular server.

also existing systems as example uses already exist under both MS and
GPL
 licenses,  so there is existing code-base re-usable to this context...

I submit the above as potentially expanding on the MIME encoding
transport
 of Email already in use and the way that is "multipart message
boundary"
 marked for each piece of a message and loss of one part breaking the
message
 and invalidating it.

Sincerely,
  Jeremy

On Mon, 2009-02-23 at 10:18 +0100, Jesrad wrote:
> Imagine for a second that the cross-grid protocol mandate somehow that
> objects made on one grid be hosted and served to clients from this
> grid, and not transfered to other grid servers / simulators (though
> the owner may have the third-party possibility of exporting from one
> and importing to another so it is hosted multiple times and thus
> exists in multiple instances).
> 
> >From there any specific policy of "DRM" would purely be a matter of
> specific grid implementation. I would say that a lot of headaches and
> flames would be averted, saving us the trouble of directly addressing
> these matters in the MMOX scope itself and leaving them for
> grid-caretakers and their own customers to discuss and decide policy
> about.
> 
> Please, everyone, let me know what you think of this.
> 
> On Mon, Feb 23, 2009 at 9:59 AM, Gareth Nelson <[e-mail]> wrote:
> > Just been talking to Adam about this and knocked out a very very rough
> > spec. It may be early in the game to discuss this issue, but it's one
> > that drives a lot of emotion in people on all sides of the debate.
> >
> > So, without further a-do, here's a rough spec for a DSL (Domain
> > Specific Language) for permissions to discuss (copied and pasted from
> > my vim session, excuse any formatting weirdness):
> > Original concept courtesy of Adam Frisby, see
> > http://www.adamfrisby.com/blog/2008/08/hypothetical-permissions/
> >
> > Very very rough thinking out loud
> >
> > Each asset has a set of metadata fields:
> >        Author
> >        Creation timestamp
> >        Last modified timestamp
> >        Logs of modifications? (TBD)
> >
> > Possible actions:
> >        Copy
> >        Modify
> >        Transfer
> >        Transfer for cash
> >
> > Each action attached to a simple function that returns a boolean value
> > if action is allowed.
> > Data types:
> >        Entity
> >                Describes a user, organisation, system or network
> >        Asset
> >                Describes an asset ;)
> >        Location
> >                Describes a virtual location, rather than a physical system
> >        Time
> >                Date and time :)
> >
> > Entity has these fields:
> >        Name
> >        UUID
> >        Class (person, organisation, system, network)
> > Optional fields for person entities:
> >        Agent domain? (TBD)
> >        System (what system is the user connecting from - may be withheld for
> > privacy reasons)
> >        Location (where in the metaverse are they?)
> > Optional fields for organisation entities:
> >        Organisation type (nonprofit/commercial/government etc)
> >        Company type (for corporations: LLC/Ltd/PLC/whatever)
> >        Address (i.e postal address)
> >        Technical contact (a person entity!)
> > Optional fields for system entities:
> >        Platform
> >        System hash (hash of various bits of hardware, HD serial and ethernet MAC etc)
> >        Network
> >        Current IP address
> > Optional fields for network entity
> >        Technical contact (heh, redundant)
> >        CIDR prefix
> >
> > Asset
> >        Name
> >        MIME type
> >        UUID
> >        Creator
> >        Creation time
> >        Last modified time
> >        Last modified by
> >
> > Location
> >        TBD (Obviously not the SL style Region/x/y/z)
> >
> > Time
> >        You need to ask? ok,
> >        Day
> >        Week
> >        Month
> >        Year
> >        Hour
> >        Minute
> >        Second
> >        All integers
> >
> > Simple comparision operators to match on what is passed to the functions
> > !=, ==, >, <, >=, <=, a few simple string functions, the usual suspects
> >
> > function prototypes:
> > copy(Entity src, Location location, Time time, Asset ass)
> >        src      == the user currently holding the asset who wishes to copy it
> >        location == the location the requesting user is inhabiting at present
> >        time     == the time the request was made at (just in case there's
> > batch processing or serious latency)
> >        ass      == the asset being copied
> > modify(Entity modifier, Asset ass, Time time, Location loc)
> >        modifier == the entity trying to modify
> >        ass      == the entity they're trying to modify
> >        time     == the current time
> >        loc      == where is our modifier while they're trying to modify?
> > transfer(Entity src, Entity dst, Location loc, Time time, Asset ass)
> >        Same as copy essentially
> > sell() is just transfer, but invoked for transfers in exchange for compensation
> >
> > The modify() function could probably do with a description (if
> > possible) of the modification being requested, for example in my own
> > work i'd want to prohibit modifications to the permissions in order to
> > enforce the GPL, others may have different requirements.
> >
> >
> > DANGER! DANGER! READ:
> >        Any system that can be proposed here can only be used to express
> > intent, it can express that intent very clearly using a DSL as i've
> > roughly
> >        spec'ed out above, but it will never be possible to actually
> > enforce it on systems that do not want to enforce it. I'll note that
> > personally I
> >        absolutely hate DRM for the most part, but if it's going to be a
> > reality it should be done right, and should allow any type of license
> > to be roughly
> >        expressed in a way that can be handled by automated systems. If for
> > no other reason than mere practicality, a decent DSL for specifying
> > what
> >        permissions an author of a copyrighted work has granted under
> > existing copyright law can be useful and saves having to pester the
> > author.
> > _______________________________________________
> > mmox mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mmox
> >
> _______________________________________________
> mmox mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmox