OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

rights-requirements message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [rights-requirements] Requirements document issues


Hello everyone,

Below are a few points that we identified after further review of the 
Requirements Document and which we felt could withstand some 
clarification or discussion.

Aaron Burstein
Dean Rowan

1. General comment: it would be helpful to the reader to explain why 
core and standard extension requirements are handled separately 
(perhaps by drawing on the charter for this distinction). This might 
help to explain, e.g., why some requirements are repeated verbatim in 
the two sections.

2. R03 should read ``Specifying Nouns''.

3. R04. To reinforce the definition of RLTC scope, perhaps this 
requirement could draw on the Introduction, as well as make the 
relationship of the building blocks of the language in R01-R03 a little 
more clear. For example,

Current R04: "The language architecture must allow for the building 
of expressions of permission based on the expressions of conditions, 
nouns (permitted, permitted-upon, and permitting), and verbs."

Suggested R04: The language architecture must allow for the building 
of expressions of permission - i.e., usage rules - based on the 
expressions of nouns (things that permit, things that are granted 
permission, or things that access to or use of is granted), verbs 
(actions that may be performed by or upon some noun), and conditions."

4. Is there a conflict between this statement in the Introduction:
"[T]he technical work of the RLTC is not directed to...[d]efine 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 [e]ncryption, or any other means 
for limiting the use of a resource" and R15 ("The language 
should make standard security features available where appropriate 
(for example, XML Digital Signature Syntax and Processing and 
XML Encryption Syntax and Processing)"?

5. R17 needs some more explanation (though this is true even without the 
Introduction).

6. R24 (which reads, in part, "The language specification must 
not require any system to support any expression in the language.") is 
in conflict with R17 ("The language must indicate which permissions are 
subject to possible revocation and how that revocation should be 
discovered if it were to occur.") and the Introduction's statement that 
"[T]he technical work of the RLTC is not directed to...[d]efine 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 [e]ncryption, or any other means for limiting the use of 
a resource".

7. Should R08 and SX04 ("Well-defined Semantics. Each expression written 
in the language must have exactly one meaning.") be qualified by 
mention of namespaces?

8. SX06-SX10 appear to violate the Introduction's statement that "[T]he 
technical work of the RLTC is not directed to...develop expressions of 
specific policies."  In particular, SX08-SX10 appear to be close to 
expressing specific policies regarding money transactions.

9. The plain-language meaning of SX14 is unclear. "Rights sequencing"  
has no colloquial meaning. What is the relationship between the 2 words 
in this heading and the full requirement: "The language must be able to 
express conditions on previously reported exercise".

10. SX15: Is this different from R25?




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC