[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [rights] rushing the spec out: two questions
Bob,
First... Characterizing this as "pro-rushing" is incorrect!. Aggressive,
Yes. When the TC was established a schedule was agreed and that schedule is
being adhered to. Aggressive schedules are greatly appreciated by the
companies we represent who want the products being developed that will use
the standard to see a return on the investment they are making in
developing these technologies.
Second ... This is not a race between MPEG and OASIS. Quite the contrary.
It is a cooperative and very importantly an orthogonal effort. The
schedules are dovetailed as are the standards. The OASIS TC is charged with
producing the "core" rights expression language and MPEG is charged with
developing the multimedia extension to the core. MPEG established its
schedule based on those organizations and industries (Content, IT, CE, etc)
agreeing that this work can be completed by July 2003 (as published). Once
MPEG establishes (by consensus) a schedule it will always adhere to it and
the RLTC is following that example. Industry trusts MPEG and has
demonstrated that trust by adopting MPEG's standards. One of the reasons is
money. A great deal of money is invested in developing any product,
standards based or not. Delays is deploying that product are very costly.
This OASIS RLTC has to build the same trust that MPEG has established, thus
a schedule.
This does not mean that new technology or requirements are ignored. MPEG
and this RLTC incorporate the technology based on new/modified requirements
in follow-on versions(amendments) to the standard. For example, MPEG-2 was
completed in Nov 1994. In July (2002) we started a new subdivision (part
11) of the standard intended to upgrade is IPMP capability. Over the years
there have been a dozen amendments just to MPEG-2 Systems. A like number
of amendments have been deployed for video as well. Not to leave MPEG-4
out of this. It too has seen new subdivisions and amendments. Most notably
the joint ITU/MPEG Part 10 AVC) video CODEC being developed.
One your points 1 & 2.
1. As I indicated above, this is not race. The publishing industry wants to
be able to use a comprehensive rights language. It has participated in the
development by submitting requirements (which are embodied in part in the
core set this RLTC is using) for its needs. The music and film industry
have done likewise as has the Consumer Electronics(CE), Broadcast and Cable
TV in the US, Japan, and Europe. One of the reasons MPEG is so successful
is the broad range of participation. It is gratifying to see new members
of the RLTC as well. No matter when you join you add to the body of
requirements and technology but as with any organization it does not stop
or retrench when new blood is injected.
The reason this effort has been divided into core plus extensions is
because it is intended to serve a wider range of industries than just
multimedia. MPEG did all of its own audio-video because it is core to its
mission. REL has an essential element in multimedia but also has needs
outside. Thus, the OASIS RLTC doing a core and others doing extensions.
2. MPEG has a complete multimedia extension together and has frozen the
spec as of July 2002 and issued its 1st ballot (CD) which will be reviewed
at the December MPEG meeting. At that time the 2nd (FCD) ballot will be
issued.
MPEG and this TC pay no attention to anyone who chooses to deploy a
product. If they want to be conformant to the standard they have to wait(
like all of us) until it is an approved standard. If they go to market
before then they do so at their own risk. MPEG and this TC will make
changes during the development period irrespective of anyone deploying a
product. This is why it is essential we adhere to our agreed schedule. A
very large investment has been made by the participants of this TC (and
MPEG) and we cannot get mass acceptance by the industries who are depending
on this until it is completed(approved by the respective standards
committee) standard.
Thank you for your attention.
Pete Schirling
Digital Media Standards
IBM Research Division
Office: +1 802 769 6123/Mobile: +1 802 238 2036/E-Fax: +1 802 769 7362
Mobile text messaging 8022382036@msg.myvzw.com
Internet e-mail: schirlin@us.ibm.com
"DuCharme, Bob
(LNG)" To: "'rights@lists.oasis-open.org'" <rights@lists.oasis-open.org>
<bob.ducharme@lexi cc:
snexis.com> Subject: [rights] rushing the spec out: two questions
09/04/2002 10:45
PM
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
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC