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

On Thu, Jan 31, 2013 at 3:43 PM, Robert O'Callahan <robert@ocallahan.org>wrote:

> On Thu, Jan 31, 2013 at 4:27 PM, Glenn Adams <glenn@skynav.com> wrote:
>
>>  On Wed, Jan 30, 2013 at 6:04 PM, Robert O'Callahan <robert@ocallahan.org
>> > wrote:
>>
>>> I do expect URIs, image, media and font formats used on the Web to be
>>> fully specified somewhere, and that is standard practice today.
>>>
>>
>> And CDMs will be fully specified somewhere as well.
>>
>
> I certainly hope that's the case. If it is, then granting my objection is
> hardly any concession at all.
>

First, every CP encryption system in use is specified somewhere.
Specification does not mean PAS. You've suggested "publicly specified to
the extent possible", and I agree with that. It may mean that a part of a
CP system is publicly specified and a part is non-publicly specified, e.g.,
requiring an NDA.

Over time what is public and what is not may change. If you accept your
"the the extent possible" qualification, then I don't see cause for your
objection.


>
>
>>
>>>
>>>
>>>>    - input method editors
>>>>    - geolocation devices
>>>>
>>>>  These do not affect interop.
>>>
>>
>> Yes they do.
>>
>
> 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.

Your objections appear to be based on issues outside the scope of EME,
namely which CDMs will be made available, whether they can be implemented
wholly from PAS, how CDMs are implemented in UAs, how multiple UAs can
support a given CDM, etc.

You also refer to interoperability, but I'm not sure what you are referring
to. At present, the HTML WG has only one definition of interoperability, as
defined in [1].

[1]
http://dev.w3.org/html5/decision-policy/public-permissive-exit-criteria.html

Are you claiming that EME as defined cannot, by definition or fault of
design, satisfy the definition of interoperable found in [1]?


>
>
>>
>>> While it is reasonable to define a voluntary registry, it is not
>>>> reasonable to require registration or to require that documentation be
>>>> fully open. Who would enforce this even if it were defined?
>>>>
>>>
>>> Whoever maintains the registry.
>>>
>>
>> No registry I'm aware of does such a thing. You are naive to believe it
>> feasible.
>>
>
> For example, http://tools.ietf.org/html/rfc5226 defines IANA procedures
> for setting up a registry, and supports placing requirements on submissions
> to the registry. It explicitly identifies the option of a "Specification
> Required" policy:
>
> Values and their meanings must be documented in a permanent and readily
> available public specification, in sufficient detail so that
> interoperability between independent implementations is possible.
>
> OK, I agree that one could define a registry that supports a subset of
potentially registrable entities, those that fully meet the PAS criteria.
That would be an enforceable criteria.

In the present case, I would not object to such a registry, though there
might not be many registrations for some time given that most CP systems
have significant non-public parts. A more effective registry would define
registrations into multiple categories, one that meets the fully PAS
criteria, and one that does not. Since you have suggested that you could
support the "public to the extent possible" qualification, then I assume
you would not object to this division.

Such a division would be consistent with other registration authorities,
such as the MIME Type Specification and Registration Procedures defined by
[2], wherein registrations in the non-standards portion of the registry
tree do not require PAS definitions (vid. section 4.4).

[2] http://tools.ietf.org/html/rfc4288#section-4.4

>
> http://www.iana.org/protocols shows that this policy is very widely used.
>
> Rob
> --
> Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur
> Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl
> bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat
> lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir
> — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb
> tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28]
>

Thank you for obfuscating your signature. I have no objection to this form.
[Perhaps you can register your CP? ;)]