Title: getting started on requirements
There are many approaches to getting organizations
that might usefully be interested in our work from caring about it; this is by
no means a black or white thing. It is, for example, certainly not the case that we should reasonably
gate the forward progress of our work on a positive thumbs-up from *all* the organizations that you mention,
for doing so would put us in a perpetual state of paralysis. There is rather a
balance to be struck.
The XrML2 core is pretty simple in its
structure: (subject, verb, direct object, conditional clause)* is its basic template.
This mirrors (not at all surprisingly) the core structure of every pretty much
every authorization framework that I can think of, a body of work which is not
exactly immature. The collective wisdom of our committee in this area surely can
lead us to understand where we are exploring well understood territory and
where solicited input likely would be most valuable.
In some contrast, the XrML2 standard
extension may find more useful goodies from a broader consideration of domains
than has heretofore occurred. But here the price of omission is less than that
of the core: this is but one extension, a well known and well publicized one
yes, but an extension nevertheless. No central or fundamental harm comes from the
omission of an element therefrom: it can live in a different extension with
comparatively minor consequences. This is not to say that producing a useful
and handy standard extension is not important, only that the scheduling
considerations are different and less compelling when striking the overall
scheduling balance.
Rather than the serial approach outlined
below, I advocate a parallel one, one wherein we pursue outreach such as is
suggested below (perhaps together with some focused personal prodding where
members of our committee have useful contacts) at the same time as we in our
own collective wisdom (which appears to actually cover quite a broad spectrum
and thus to be a reasonable sounding board) articulate the requirements that we
can see; this we should be able to do in quite short order. Having done that
exercise, we will be able to easily understand what we have well in hand and
what we are lacking, and so able to judge the importance of obtain à priori design
input from particular external organizations.
There is also another perspective on this.
MPEG21 is moving forward apace with their work involving XrML. It is in my
understanding unlikely (though others here certainly have more detailed
knowledge than I on this topic) that our TC will be able to significantly alter
the schedule on which they do so. If we fail to connect with their schedule by
some means or other, they will, I believe, in the end create a fork of XrML,
the core and standard extension included. It would then seem to me of precious little
relevance of how much other organizations believed “that our TC is going to speak for them.”,
for they would have an alternate and arguably
more compelling source for this technology. MPEG21 is by no means the only
customer of our work, but it is equally by no means just one among equals.
Bob
-----Original Message-----
From: Glushko, Bob
[mailto:]
Sent: Thursday, May 23, 2002 6:54
AM
To:
Cc: ''
Subject: [rights] getting started
on requirements
I'm eager to start getting requirements and it strikes
me that there is significant overlap between that process and the liasion
process with related standards efforts and other organizations with interests
in DRM.
Specifically, the best way to achieve broad consensus
and buy-in on a DRML is to
1)identify the relevant organizations
2)invite them to review the current specifications,
especially the use cases (since these are the most accessible point to get
started), and submit any new requirements or use cases, along with any schedule
constraints or milestones in their activities that present opportunities for
synchronization
[i'm reacting here to the unidimensional view
in our kickoff meeting that seemed to make the MPEG21 milestones the only ones
that matter to us]
3)do a careful job of analyzing their requirements
I've thought about the impact of a request like this
on standards activities that I'm currently involved in (like UBL) and I suspect
that we'd need to give the organizations we identify in step (1) here at least
a month to get back to us. It is unreasonable to give them any less time;
for example, in the UBL case, there is intense work going on to get ready for a
1-week face to face meeting the week of June 2-6, and nothing is going to get
higher priority. So the earliest there could be any serious consideration of
DRM issues would be the second week of June, and that ignores the "catch
up" time needed when you get back to work after being out of touch at a
standards meeting for a week.
My point here is that we have to be realistic about
the schedule for collecting requirements from other standards efforts. If we
don't give people sufficient time to do this according to their own processes,
they will not buy into the idea that our TC is going to speak for them.
I also think that we need to cast a wider net than
simply the standards organizations that Brad listed on Tuesday. We need to
identify some in the user community rather than the technology or content
communities because I think that in the former is where our acceptance and
credibility problems are most likely to appear. I will start down that road
assuming that Brad and others already have a handle on the groups who are
creating their own DRMLs.
-bob
Robert J. Glushko, Ph.D.
Engineering Fellow
One Market Street, 13th Floor
Steuart Tower
San Francisco CA 94105
415-644-8731
