[rights-requirements] RE: [Fwd: Core vs. Non-Core]

["Reddy, Hari" <Hari.Reddy@CONTENTGUARD.COM>]

Title: RE: [Fwd: Core vs. Non-Core]

Hi Patrick:
Again my apologies...you should have been able to send this to the list last week. I am copying OASIS in this post to try to resolve. I am having problems sending information in myself this morning and Karl has been helping me by forwarding my postings...

Thanks for your note...
I will try to answer some of your questions/points by clipping from your original email...:

From Patrick:
It appears to me (and this may be obvious to everyone else)  that Hari's
parsing of the requirements into core vs. domain reflect an a priori
acceptance of XrML 2.1 as it stands now. Is that a correct reading?

Hari:
The charter states (http://www.oasis-open.org/committees/rights/#charter):
2. Use XrML as the basis in defining the industry standard rights language in order to maximize continuity with ongoing standards efforts.

With that pointed out, the requirements were parsed using the notion of a core, standard extension and domain extension. This architecture was actually pointed out in the Reuters requirements set. Also, as Thomas DeMartini stated in a previous email (I can't seem to access the list serv to give you a pointer from my office but it was posted on 08-22-02):

Thomas DeMartini writes :
--------------------------------
...
What this means is that we want to get something out to the world, a set of requirements that we all agree on.  There are several things that this does not mean.

a) This does not mean that input for requirements has been closed.
b) This does not mean that XrML v2.1 satisfies all the requirements in requirements v1.0.
c) This does not mean that XrML v2.1 does not satisfy all the requirements in requirements v1.0.
d) This does not mean that our first version of the rltc spec will satisfy all the requirements in requirements v1.0.
e) This does not mean that our first version of the rltc spec will not satisfy all the requirements in requirements v1.0.

f) This does not mean that our first version of the rltc spec will satisfy all the requirements in requirements v1.1.
g) This does not mean that our first version of the rltc spec will not satisfy all the requirements in requirements v1.1.

What it does mean is that we have a set of requirements we call 1.0, and we publish it as a document that we think we can go forward with, and that if there are any people who would like to use the spec that do not see their requirements there we would expect their feedback.

 
--------------------------------

From Patrick:
I would rather develop the requirements (BTW, are there any internal requirement
documents from ContentGuard reflecting the requirements for XrML that
can be shared with the group?) and then evaluate XrML in light of those
requirements.

Hari:
One of the customers of the Requirements documents is the Specification SC which will evaluate the requirements and provide a technical response using the current baseline. This is the evaluation step that you highlighted and was also mapped out when we started this process. With respect to the ContentGuard requirements, ContentGuard submitted a 50+ page document to the ISO/JTC1 (MPEG) and OeBF processes which have subsequently submitted their requirements to our TC.

Hope this answers your points and thanks again for your help...

Regards,
Hari

-----Original Message-----
From: Patrick Durusau [mailto:pdurusau@emory.edu]
Sent: Tuesday, August 27, 2002 2:11 PM
To: Hari.Reddy@CONTENTGUARD.COM; robin@isogen.com
Subject: [Fwd: Core vs. Non-Core]

Hari,

A message I posted last week that appears to have not made it to the list.

Thanks!

Patrick

-------- Original Message --------
From: - Wed Aug 21 16:57:49 2002
X-Mozilla-Status: 0003
X-Mozilla-Status2: 00000000
Received: from desdemona.cc.emory.edu (desdemona.cc.emory.edu [170.140.204.1])  by
enceladus.cc.emory.edu (8.8.8/8.8.8) with ESMTP id NAA16017     for
<pdurusau@mail.service.emory.edu>; Wed, 21 Aug 2002 13:49:56 -0400 (EDT)
Received: from imf01bis.bellsouth.net (mail201.mail.bellsouth.net [205.152.58.141])     by
desdemona.cc.emory.edu (8.10.2/8.10.2) with ESMTP id g7LHoGa10464       for
<pdurusau@emory.edu>; Wed, 21 Aug 2002 13:50:16 -0400 (EDT)
Received: from bellsouth.net ([65.81.145.8]) by imf01bis.bellsouth.net
         (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with
ESMTP          id
<20020821175149.QZXU12335.imf01bis.bellsouth.net@bellsouth.net>;
   Wed, 21 Aug 2002 13:51:49 -0400
Message-ID: <3D63CEEF.8030102@bellsouth.net>
Date: Wed, 21 Aug 2002 13:33:35 -0400
From: Patrick Durusau <pdurusau@bellsouth.net>
Reply-To: pdurusau@emory.edu
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010914
X-Accept-Language: en-us
MIME-Version: 1.0
CC: rights-requirements@lists.oasis-open.org, rights@lists.oasis-open.org
Subject: Core vs. Non-Core
References: <3D63C61D.3090408@bellsouth.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Greetings,

First, let me say that during the very brief time I have been associated
with this group that I have rarely seen anyone work as hard as Hari in
terms of collating the various requirement documents.

I am working through the core document more carefully than my first read
and wanted to check something that came up in this mornings conversation.

It appears to me (and this may be obvious to everyone else)  that Hari's
parsing of the requirements into core vs. domain reflect an a priori
acceptance of XrML 2.1 as it stands now. Is that a correct reading?

If we are submitting requirements for a rights expression language, I
would expect the next step to be determining a set of requirements for
such a language. Once those requirements have been determined, then and
only then would we turn to either constructing such a language or
evaluating a candidate for such a language, such as XrML 2.1.

I don't doubt that ContentGuard and probably Hari personally have saved
the group months of time in the standards process by their development
of XrML but, I don't think the classification of requirements by the
standard that hopefully will be seen (and used) as meeting those
requirements (not the other way around) is very helpful. I would rather
develop the requirements (BTW, are there any internal requirement
documents from ContentGuard reflecting the requirements for XrML that
can be shared with the group?) and then evaluate XrML in light of those
requirements. I don't think that would take any longer than the present
process and would make the mapping of requirements to XrML a little
easier to follow.

Patrick

--
Patrick Durusau
Director of Research and Development
Society of Biblical Literature
pdurusau@emory.edu