RE: [rights-requirements] Introduction to the Requirements Docume nt

["DeMartini, Thomas" <Thomas.DeMartini@CONTENTGUARD.COM>]

Title: RE: [rights-requirements] Introduction to the Requirements Document

I have a few concerns:

A. (pretty uncontroversial, I think).  Where it says "object or service" we should include the plural case as well.  For instance, one "rule" could be applicable to *several* objects or services.  Also, I'm not sure "object" and "service" are broad enough to capture all kinds of resources.  What about a computer game "special move", would this be classified as an "object"?  Maybe the fix for both of these is as simple as adding a "for example" in the sentence, so it'd read something like "by 'permissions' we refer to, for example, a set of usage rules...".  Does that work?

B. (more of a general concern).  The words "usage rules" don't really clarify much for me.  They seem to be as overloaded in interpretation as the word "rights".  In particular circles, "usage rules" means one thing, but in other circles it means other things.  In colloquial usage, it doesn't really mean anything.  You know, I go to a party and someone asks what I do and (sadly :-) I start talking about "usage rules" and they are all clueless.  But they do have a pretty good grasp at "permissions".  So, personally, I have a hard time seeing how describing "permissions" as "usage rules" helps any -- in fact it adds confusion for me.  That said, I only offer this up for discussion.  If I'm the only one that this doesn't help, I'm willing to just accept that the definition of "usage rules" is what I understand "permissions" to be so that we can move forward.  But I do ask that people first validate that they really think they are helping by introducing this concept of "usage rules" or if we just end up being overly-exact when "permissions" was already exact as far as everyone was concerned?  Or, more to the point, I think the proposed addition would be great if someone actually misunderstands "permissions", so my question is "is that the case?"

Thanks,
Thomas.

] -----Original Message-----
] From: John Erickson [mailto:john_erickson@hplb.hpl.hp.com]
] Sent: Wednesday, October 16, 2002 11:09 AM
] To: rights-requirements@lists.oasis-open.org
] Subject: Re: [rights-requirements] Introduction to the Requirements
] Document
]
]
] As discussed, here is the "tweaked" version of Parama's
] proposed introduction,
] based upon his email version. The added phrase begins with "To be
] rigorous..."...John
]
] ----------------------------------
]
] This document further elaborates on the scope of the RLTC by
] listing positive
] requirements for various aspects (core, standard extension,
] and governance) of
] the RLTC.
]
] While the charter of the RLTC is written in words that are
] meant to draw upon
] terminology and concepts represented in existing bodies of work in the
] marketplace, the requirements document is intended to stand
] alone and uses
] colloquially accepted terminology.  Thus, in this document we
] use the colloquial
] words equivalent to the marketplace concept of rights:
] permissions granted by
] one entity to another.
]
] To be rigorous, by 'permissions' we refer to a set of usage
] rules applicable to
] some object or service, that may used by a compliant
] interpreter to control a
] user's access to and usage of the object or service. The
] 'user' in this case
] might be a human or a hardware or software component.
]
] As such, the technical work of the RLTC is *not* directed to
]
] * Develop specific terms that will be used to write
] expressions that are
] pertinent to some domain such as
]
]  * Specific usage permissions and conditions specifically for
] content and
]  * Specific usage permissions and conditions specifically for
] other types of
] resources.
]
] * Develop a language or system that addresses legal rights
] and processes.
] Examples of these rights include, but are not limited to,
] those legal rights
] termed as "fair use rights" and contractual rights.
] * Develop expressions of specific policies (such as "every
] e-book can be copied
] once" or "any doctor may review his patients' records").
] * Develop a language or system that addresses other functions
] that may or may
] not be necessary in the bilateral communication between
] componentry. Examples of
] these functions include, but are not limited to, messaging,
] querying, and
] negotiation between componentry. As such, the technical work
] of the RLTC is not
] concerned with
]
]  * Defining a means for expressing exercises of permissions.
]  * Defining a means for expressing preferences regarding
] automated exercise of
] permissions.
]  * Defining a means for expressing the desire to receive permissions.
]  * Defining a means for expressing the desire to exercise permissions.
]
] * Define a DRM system standard nor a road map for the
] creation of a collection
] of DRM system standards nor any other component that may be
] required in a DRM
] system such as
]
]  * Encryption, or any other means for limiting the use of a
] resource and
]  * Resource identification and trust model prescription, or
] any other means for
] determining the legal authority to originate permissions.
]
] While the language that is standardized by this committee may
] be expressive
] enough to express policy associated with the aforementioned
] areas within the
] appropriate contexts of the problem addressed, the scope of
] this committee is
] not to solve the bigger problem. The work product of this
] technical committee
] will be one component of a larger ecosystem of componentry
] and workflows that
] will address those issues that are not addressed by this
] technical committee
] itself.
]
]
] | John S. Erickson, Ph.D.
] | Hewlett-Packard Laboratories
] | PO Box 1158, Norwich, Vermont USA 05055
] | 802-649-1683 (vox) 802-371-9796 (cell) 802-649-1695 (fax)
] | john_erickson@hpl.hp.com         AIM/YIM/MSN: olyerickson
]
]
] ----------------------------------------------------------------
] To subscribe or unsubscribe from this elist use the subscription
] manager: <http://lists.oasis-open.org/ob/adm.pl>
]