[rights] rushing the spec out: two questions

["DuCharme, Bob (LNG)" <bob.ducharme@lexisnexis.com>]

I have two questions about the pro-rushing sentiment voiced by several
people in today's general conference call. Both are based on my
understanding of the argument for rushing being that if we don't move
quickly enough to fill the DRM gap in MPEG, MPEG will fill it themselves,
and people will use their DRM language instead of the OASIS one.

Questions:

1. Who are these people that won't wait? The answer doesn't have to be that
specific; for example, "the consumer electronics industry, the X industry,
the Y industry..." I'm fully confident that the publishing industry would
not, six months from now, jump on an MPEG DRM specification because it beat
the OASIS one to Release 1.0 by two or three months, and I'd like to know
which industries would. If the answer is "everyone using the MPEG standard,"
I'd still like to hear this broken down into a few industry categories. Many
industries that won't be using the MPEG standard still need a DRM language,
and are hoping to see it come from OASIS. If we say that we'll take care of
them in 1.1, it still doesn't address the question of who will use an MPEG
DRM spec instead of ours because we didn't move quickly enough, which is one
of the main justifications given for our rushing. 

2. How much of a DRM language does MPEG  have together now--that is, is the
OASIS RLTC's head start as big as I think it is, or does MPEG have a DRM
specification in progress that is on track to be turned into something that
could be released in six to eight months and viably compete with a solid
XrML upgrade?

Those are my questions, and here's my general opinion: everyone agreed that
the OASIS RLTC would not be rubber-stamping ContentGuard's existing work to
turn it into the OASIS RL 1.0. I thought of this when I heard today how
badly we need to "take what we have and get it out there" (please correct me
if I'm misquoting) because what we have is XrML 2.1, a ContentGuard product.
If we add a couple of things and essentially release XrML 2.2 as ORL 1.0, we
wouldn't be fooling many of the people who we originally assured that this
was not a rubber stamp job. 

Bob DuCharme
Consulting Software Engineer, LexisNexis
Data Architecture, Editorial Systems and Content Engineering