[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