[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [rights] rushing the spec out: two questions
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC