Possible Bug - is EME WIPO 1995 Compatible or not?

Mark,

If EME is not compatible with the WIPO Internet Treaties, which from what I
can see it is not, then it is a bug which needs to be fixed. Sorry about
dropping it into an existing thread, my screw up, now fixed.

So, am I missing something and is it compatible? I'll admit that I'm more
comfortable with Fortran and Basic, I'm one of the antiques who learned
programming using punch cards before Apple or Microsoft existed.

Wayne




On Wed, Jun 12, 2013 at 10:31 AM, Mark Watson <watsonm@netflix.com> wrote:

>
>
> Sent from my iPhone
>
> On Jun 12, 2013, at 12:35 AM, Wayne Borean <wborean@gmail.com> wrote:
>
>
> Hmm. You do realize that EME is not compatible with the WIPO Internet
> Treaties?
>
>
> Is your comment related to the thread in which you posted it (which is
> about MSE not EME) ? Can you explain further ?
>
> ...Mark
>
>
> While a private firm like Microsoft or Apple could (and do) build software
> which isn't WIPO-1995 compliant, making a Web Standard that isn't WIPO-1995
> compliant would be a huge mistake.
>
> Wayne
>
>
>
> On Tue, Jun 11, 2013 at 7:02 PM, <bugzilla@jessica.w3.org<bugzilla@jessica.w3..org>
> > wrote:
>
>> https://www.w3.org/Bugs/Public/show_bug.cgi?id=22329
>>
>>             Bug ID: 22329
>>            Summary: [MSE] TextTrack attributes settable in conflict with
>>                     the html spec
>>     Classification: Unclassified
>>            Product: HTML WG
>>            Version: unspecified
>>           Hardware: PC
>>                 OS: All
>>             Status: NEW
>>           Severity: normal
>>           Priority: P2
>>          Component: Media Source Extensions
>>           Assignee: adrianba@microsoft.com
>>           Reporter: giles@mozilla.com
>>         QA Contact: public-html-bugzilla@w3.org
>>                 CC: mike@w3.org, public-html-media@w3.org
>>
>> "partial interface TextTrack {
>>   attribute DOMString kind;
>>   attribute DOMString language;
>> }"
>>
>> The TextTrack interface in the html spec has readonly attributes of the
>> same
>> name. I think the idea is to use specific constructors as the only way to
>> pass
>> these in, or have them created by the parser for in-band text tracks and
>> <track> elements.
>>
>> Do we need this interface? If it's muxed with the parent media element's
>> source
>> stream, the in-band text track support should cover it, and if it's
>> external,
>> the media.AddTextTrack and TextTrack.addCue methods should be sufficient
>> to
>> implement dynamic subtitles with minimal complexity.
>>
>> --
>> You are receiving this mail because:
>> You are on the CC list for the bug.
>>
>>
>