Re: CfC: to publish Encrypted Media Extensions specification as a First Public Working Draft (FPWD)

On Thursday 2013-01-31 16:39 -0700, Glenn Adams wrote:
> On Thu, Jan 31, 2013 at 3:43 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
> > Please explain how. I'm not aware of cases where specifying IME behavior
> > was needed to solve interop problems, even though I've worked on Mozilla
> > IME code in the past.
> >
> 
> My intent was to list modular extension mechanisms defined or implied by
> W3C specifications. IMEs and geolocation devices come under this category.
> As such, they are like CDMs which are effectively an abstraction barrier
> that enhances modularization and aids specification of EME behavior that
> isn't dependent on CDM specifics.

The fundamental difference between IMEs and CDMs that's relevant
here is the material that is exchanged between parties over the
network or via APIs.

If a user enters text using an IME, what ends up being sent over the
network (in a form submission) or exchanged via an API (say,
HTMLInputElement.value) is the resulting Unicode text.  In other
words, when I choose the pinyin Chinese IME that I have installed
and type the text "beijingshi1" (where the "1" chooses the first
option I am presented), the data sent over the network (or
accessible via the DOM) is "εŒ—δΊ¬εΈ‚" rather than the tuple
("beijingshi1", "ibus pinyin IME").  (Sure, the author *can* look at
the raw key events, but that's not the preferred way of doing things
when there's text in the interoperable Unicode format available.)

With CDMs, on the other hand, the data communicated between parties
is the tuple (encrypted data, key system).  This means the
underlying data are meaningless unless both parties know what the
key system is.  This, in turn, is why it's important that the key
systems or the content decryption modules implementing them be
registered.

-David

-- 
π„ž   L. David Baron                         http://dbaron.org/   𝄂
𝄒   Mozilla                           http://www.mozilla.org/   𝄂

Received on Friday, 1 February 2013 03:48:44 UTC