HTML Interim Face to Face

23 Apr 2013


adrianba, chaals, Jungkee_Song, Bryan_Sullivan, Jonghong_Jeon
paulc, rubys


<gitbot> 01[13html01] 15rubys pushed 2 new commits to 06feature/whatwg: 02https://github.com/w3c/html/compare/5069600eb2e9...a9ffe895f193

<gitbot> 13html/06feature/whatwg 145eb5e2b 15ianh: [e] (0) Clarify what we mean by 'poster frame' of an animation....

<gitbot> 13html/06feature/whatwg 14a9ffe89 15ianh: [e] (0) Be clearer about how preparsing handles running out of bytes....

<darobin> MikeSmith: you're around man?

<MikeSmith> darobin: here now

<MikeSmith> at Denny's near my hotel

trackbot, start meeting

<trackbot> Date: 23 April 2013

<scribe> scribe: Josh_Soref

<scribe> scribenick: timeless


[ Everyone introduced themselves ]

Agenda bashing

paulc: we'll start with an Unconference
... ruby has this page open with the schedule
... there are requests from the Media TF
... for a session on EME
... - current bugs
... - Accessibility TF wants to talk w/ them about alternate media in the clear
... I'm proposing to do these after lunch
... and i'm proposing to do MSE first
... it should take 30 minutes?
... eric(?)
... i'm assuming lunch is 12p-1
... we'll do MSE 1p-2
... then EME after that for 90 mins
... there are a fair number of open topics there
... a larger section on Candidate REC status
... - update on testsuite, coverage, status
... krisk wanted to talk about github and branching
... i suggested working on figuring out which parts of the document are passing exit criteria
... and talking about Features AT RISK
... MicroData met yesterday
... i suggested to darobin that this is a fairly large topic
... that we start it this morning
... we'll finish this section w/in half an hour
... and then the rest of the morning to start on [hand-pointed] topic
... the WG has 2 docs out to CR and our job is to get them past
... ruby: can you put CR status for 9:30a-10:15
... and part 2, 10:30a-12noon
... that covers the big things
... for this morning and early this afternoon
... Moving the polyglot spec forward
... eliot?

eliot: i want to hear where people's feelings are
... it could be 10mins or 45mins

<CyrilRa> Anyone on phone bridge? Been on bridge from Agenda for a while (and on IRC Channel), on my own…

paulc: ruby, open a slot tomorrow morning at 9am
... darobin heartbeat, can i lump that w/ misc for tomorrow morning

darobin: sure

paulc: we want to talk about various documents
... and we want at least oral concurrence

<krisk> krisk: F2F wiki http://www.w3.org/wiki/HTML/wg/2013-04-Agenda

<eliot> hober

hober: did we schedule EME?

<CyrilRa> Update agenda to reflect IRC Channel

paulc: yes
... assigning transcript to audio/video
... Accessibility TF wanted this
... JF_, do you have any idea how long it will take?

JF_: 30mins? maybe longer

paulc: ruby, put in post coffee tomorrow morning
... Web Perf issues re:HTML5
... put after coffee in misc 2
... session on wiki "Extension Spec Status"
... Moving Image Description aka Longdesc
... - it has a FPWD, and the TF intends to take it to LC
... chaals ?

chaals: at least 3 minutes

paulc: put it in misc 2

janina: some of us won't be here then

paulc: ok, ruby,, create a slot today @ 11:45a
... i think that covers everything on the list
... anyone have anything else?
... darobin, looks like we have time for another testing slot tomorrow

darobin: if we need it

paulc: this group needs to figure out how to use the time
... we need to figure out which parts need testing, and which don't
... if we need to drive through the spec section by section, that's what we'll do
... call that "candidate testing part 2" tomorrow afternoon
... other topics?

<scribe> ... "New features for html 5.1?"

plh: can we have a slot for HTML WG Charter?

paulc: how much time?

plh: 30mins

paulc: any other topics?

plh: paulc, wanted Charter tomorrow

paulc: ok

CR and Testing

paulc: * HTML Test Suite coverage, gaps and status
... * Usage of Github and branching (Kris)
... * Review of which parts of HTML5 pass the "passive exit criteria"
... * Status of HTML 5.1 and Canvas open bugs
... * Status of Features at Risk (more, less?)
... * Getting Microdata to CR (Editorial team)

Getting Microdata to CR (Editorial team)

paulc: i think we can do Microdata first
... does an editor want to speak?
... in December when we took HTML5 and Canvas to CR
... we had an Objection in taking Microdata to CR
... which is why it didn't go out at the same time
... we talked about this as chairs and editors
... i think we need a further update

MikeSmith: we're even further blocked than before
... we'll have fewer implementations potentially than when we spoke a few months ago
... the Google Blink team decided to yank the implementation of the Microdata DOM API
... it's likely to disappear from WebKit also
... the Microdata specification defines some attributes that are extensions to the HTML language
... we don't have implementation conformance requirements
... we only have conformance requirements for validators
... the one thing we have is this DOM API
... we have 2
... we had one in Opera
... my understanding is Opera is End-Of-Lifing their web engine (Presto)
... and they'll be shipping WebKit/Chromium
... I don't think we can count the Opera engine
... we have one implementation in Mozilla (Gecko)
... unfortunately
... in discussing w/ the Chrome team
... they're not just yanking the implementation
... they're not interested in implementing the specification as spec'd
... we could work to go to CR
... but, six months from now, we're unlikely to be able to exit
... also, editorally
... there's no industry momentum behind Microdata
... it was nice at the time
... it lit a fire under the RDFa to force them to make their API fit to market
... it pushed the RDFa partisans to align w/ what we asked them to do
... now that it's done
... I don't think the entire world needs to work on two different
... Practically speaking, Schema.org started w/ Microdata
... but now RDFa has a lite version, which is quite usable

<darobin> [despite its terrible name]

MikeSmith: I don't think orgs like Schema.org which are using embedded metadata
... want to do things twice
... I don't think the investment is necessarily needed to continue
... I, myself, don't think it makes sense to continue to pursue this

chaals: I put myself on the queue to call Bollocks
... 1. Microdata is in large part not directed at browsers
... it's the least interesting application in many cases
... browser implementations aren't always the implementations you're looking for
... in some things we do in HTML
... we couldn't care less if it's used in the browser
... things like Authoring systems
... for Microdata, it's for Data management systems
... you might lose Browser implementations
... Yandex has a Microdata implementation for schema.org
... and we can see interoperable

<CyrilRa> Any update on phone bridge?

chaals: we don't really care if it's implemented in a browser
... we want to see if it's really implementable
... the approach for "what is a valid implementation requirement"
... should be opened up a bit
... there are boatloads of Microdata in Russia
... we use Microdata in Yandex, which we implemented early
... so there's a lot of it
... we lead the Russian market
... as Google leads the US market
... i'm not necessarily disagreeing w/ MikeSmith 's conclusion
... but i'm disagreeing your steps

<Zakim> MikeSmith, you wanted to thank Chaals for volunteering to serve as the W3C editor for the Microdata CR spec

MikeSmith: if you are invested in it
... then you're welcome to edit

rubys: i want people to focus on actual recommendations
... MikeSmith was talking about Terminating as a NOTE
... and that was what i heard
... but from chaals, you said we don't care about the html bit?
... but we want the rest?

chaals: i was trying to avoid committing to find an editor

rubys: if we don't have an editor, we should terminate

chaals: we should do things for reasons that make sense
... if we don't have an editor, no one cares about it, we walk away

paulc: when chairs did a call for editors last summer
... we had a lot of answers, but they had limited experience
... and we turned them down
... don't assume the only possible editors are in the room
... people might not have a primary interest in Microdata
... but they might volunteer to get editing experience
... the right way forward is for chairs to do a call for volunteers

MikeSmith: yes
... if a WG, esp a high profile WG like this
... puts out a call for editors
... we'll have a lot of people who will step up and say "yes"
... "oh, btw, what is Microdata?"
... we don't want people who don't know what it is to step up
... they won't stick around
... abundance of potential editors isn't a solution

rubys: you suggested the APIs are AT RISK
... we could take some decision on the APIs
... you were suggesting is that the parts that chaals spoke to
... search engines, processing systems
... are the attributes
... and we could propose to move them somewhere else?
... when we went to CR
... we had a missing section
... we spoke about moving it to the HTML base spec

paulc: i don't think people in the room understand what happened at the Director's TR Call for Microdata
... I want to refresh people's minds

MikeSmith: i'm trying to remember that call
... if someone else on the call?

darobin: we had a Director's Call to move Microdata to CR
... during the call, we noticed a section had gone AWOL
... there was a merge error from the WHAT WG spec
... the call failed, because we couldn't ship a spec missing an entire section
... after which the Blink announcement happened

rubys: three things
... 1. API
... - no one in room has interest
... 2. Definition of Microdata
... - Yandex is interested, but not necessarily to find an editor

chaals: if you want the spec in Russian...

rubys: 3. Microdata in HTML
... which is currently in the HTML spec
... it should probably be tombstoned
... if decision is to make it a FINAL NOTE
... it should probably be moved back

paulc: why wouldn't we fix the missing section
... and go to CR w/ the API marked at risk

rubys: if there's interest and an editor
... that makes sense

paulc: trying to make sense w/o worrying on editor

darobin: i don't think we should focus on finding an editor
... i don't think it's a lot of editorial work
... tombstoning, dropping API, etc, all are short
... if there's strong interest from Yandex
... we can probably take to CR w/o the API
... if you want us to take it
... show us another company w/ interest

MikeSmith: we made a decision a long time ago to split the Microdata stuff out of the HTML spec
... the upstream spec is continugous
... we could put it back there/leave it there
... part of why we pulled it out was political
... to show we didn't want to give it an unfair advantage over RDFa
... we could put it into HTML.next

paulc: that's another
... alternative
... 1. go to CR w/ part of spec AT RISK
... 2. archive w/ WG NOTE
... 3. fold the attributes in HTML for 5.1 - as Yandex, and schema.org use them

MikeSmith: 3 is what i'd suggest
... let's reduce the amount of extra work for myself

darobin: not just you

paulc: darobin, how much work is it to integrate back into HTML5.1?

darobin: even less than the others

<Zakim> MikeSmith, you wanted to say that another possibility is that we just put Microdata back into the spec where it started from

rubys: MikeSmith, what do you propose to do w/ the API?

MikeSmith: leave it there for now

paulc: anyone in the room want to express an opinion on the three options?
... 1. go to CR w/ part of spec AT RISK

<darobin> [we could even come up with a better API that also covers RDFa]

paulc: 2. archive w/ WG NOTE
... 3. fold the attributes in HTML for 5.1

chaals: we'd like it to go to CR, so it isn't spinning around

hober: i agree w/ MikeSmith, roll it into 5.1

paulc: other opinions?

Mark_Vickers: confused
... MikeSmith spoke about this
... can we get multiple implementations
... is everyone turning away from this?
... option 3, doesn't that cause more risk?
... to the 5.1 spec
... not getting multiple implementations?
... not getting things people want?
... and it seems to contradict the extensions spec model

darobin: i understand your confusion
... putting it in 5.1
... a. it's less work for us
... b. it gives us more time, 5.1 target is 2016
... it doesn't push us to make a decision in the next six months
... give people a chance to use it, or give us a chance to notice it's completely dead
... c. re: relationship to extension specs
... it interacts w/ lots of other sections
... it interacts w/ syntax, drag and drop, etc.
... it's difficult to extract

paulc: other questions/comments?
... chairs will take an action item for a proposal
... need to figure out if we want to do a CfC or something else, I expect to hear an objection if we do a CfC

chaals: i doubt Yandex will raise an Objection
... unless we offer to pony up resources
... this isn't a hill we'll die on
... strong objection path is unlikely

paulc: what if we move the attributes to 5.0?
... the reason this is in microdata5.0
... was because the WG made a decision to split out the content
... it's the attributes you're most interested in, right?

<rubys> ACTION: sam to bring microdata proposals to the working group 1) terminate as a note, 2) take attributes to CR, 3) move to 5.1 [recorded in http://www.w3.org/2013/04/23-html-wg-minutes.html#action01]

<trackbot> Created ACTION-225 - Bring microdata proposals to the working group 1) terminate as a note, 2) take attributes to CR, 3) move to 5.1 [on Sam Ruby - due 2013-04-30].

chaals: yes

paulc: why can't we just fold this back into 5.0?

chaals: same political reasons as why we split it out

MikeSmith: if we put the attributes back into the spec, it won't affect progress of the spec
... we don't have conformance requirements

paulc: right, that's why i asked
... but chaals, i think you're right, we'd get an Objection

[ Time check ]

HTML Test Suite coverage, gaps and status

darobin: i suppose most of you are familiar w/ W3 process
... one of the things you need to go from CR to PR
... is a Test Suite
... to prove that the nice piece of prose is supported by implementations
... when you have a spec as large as HTML
... writing a Test Suite is a big task
... we put a lot of effort into it
... we did an extra push
... to ensure we have a good Test Suite, so we can exit CR on schedule
... a few testing topics that I want to introduce
... the testing repository has moved to github

<plh> zaki, this is html_cg

<krisk> https://github.com/w3c/web-platform-tests

darobin: we have a relatively new repo on github
... in addition to HTML tests
... this is the repo for all w3 related technologies from W3C
... possibly also for Khronos
... there's 2d canvas
... webapps tests
... an html directory - the html test suite
... in github fashion
... if you want to contribute
... you fork the repo
... clone it locally
... make changes
... push changes back
... make pull request
... someone working on test review team
... will give feedback or merge in
... we have a fairly straightforward workflow
... we had a test suite
... we noticed the bottleneck was in reviewing tests
... people would write them, submit them
... but they'd get stuck there
... if you're interested in helping review tests
... writing tests is difficult if you're not familiar w/ the process
... but reviewing them is a good way to start
... we have w3c-test.org
... it has a web platform test subdirectory
... for HTML, see we have a breakdown

<darobin> http://w3c-test.org/web-platform-tests/master/tools/coverage/?algos=2&assume-idl=85&assume-tooling=50&idl=5&level=1&propdef=8&reftest-factor=2&review-success=50&review-time=30&rfc2119=4&sort-by=id&spec=html&test-time=60

JF_: where is the Accessibility section?

darobin: this is html
... w3c has a fellow on loan from Facebook
... tobie

<chaals> Web Platform Tests

darobin: and they're working on figuring out how to make the accessibility testing side work
... accessibility testing is harder to make automatable
... they're considering Web Driver

JF_: there's a community of driven people
... we could put Brawn instead

darobin: we're in the process of raising funds
... and trying to develop tools, to do test running, result gathering, analysis, etc.
... for manual tests, we have a prototype, we're not happy w/ it
... i wouldn't want to launch a big crowd sourcing on it now
... they'd give up on it within a day
... for CSS, there are plenty of things you can't automate
... we want to push a crowd-sourcing effort
... no timeline for that
... plh ?

plh: we're going to develop the infrastructure
... i don't think we'll be in a position to push for crowd-sourcing w/in 6 months
... and it's hard to align with a timeline
... i can't rely on crowd-sourcing if i need to deliver by 2014

darobin: you were talking about crowd-sourcing writing of tests
... but JF_ was talking about crowd-sourcing running

JF_: we have a strong community, both professional and volunteer
... who'd be able to run tests

plh: for long term, we'd like to rely on Driver
... i don't think we'll rely on it before next year

darobin: Accessibility testing is definitely part of it

plh: when we test <track> or [Media].mediagroup, it would be part of that

darobin: to give you a sense of the size of the Test Suite
... we have over 10,000 tests

<chaals> [/me wonders about webdriver running accessibility tools that are not built into browsers - but not sure that's a critical thing to say here]

darobin: we want 26,000

paulc: from my point of view, this is going at it ass-backwards
... HTML5 WG went into CR w/ a passive exit criteria
... that we don't need to test things if we claim we have interop
... we have a grant to not to write tests
... i understand there's a wide desire to have a broad test suite for the platform
... our job in this WG is to get out of CR
... if we believe we have compat in an area, then we don't need tests there
... this is creating a higher mountain than we have to climb

darobin: there are 2 things
... `the test suite we need to exit criteria`

paulc: no
... we need test results
... you don't need a test suite to get out of CR
... you need interop proof that the director will accept
... this WG went into CR w/ another way to do that as well
... "if we can identify parts of the spec that are broadly implemented
... by implementations out there
... then we don't need a test suite for that"

darobin: we would need 8.5 years to finish this
... i don't think our goal is to exit CR in 2021
... which is why, within the context of exiting CR for the HTML WG
... there's a subset we need to target
... we don't need 100% in all these boxes
... it's important to have syntax, and some other things
... but we need to prioritize
... figure out which areas we feel definitely need a test suite to demonstrate interoperability
... i don't think we can go to the Directory and say we don't have any tests
... this group needs to decide as a group which to work on
... we have 6000 tests waiting for review
... testing for Video, Track, things we know are new

mjs: it makes sense to prioritize the tests
... stating the criteria as the new features that need tests
... isn't the right reason
... <video> is possibly not what we need tests for
... we have lots of real world consumers
... whereas microdata has less use, or older elements
... even though they've been around forever
... e.g. if they were loosely defined before and are now strongly defined
... we should ask "do we have some reason other than a test suite to decide if something is strongly interoperable"

[ laughter re using microphone ]

krisk: master branch has WebGL and other stuff
... really concerned we're losing focus
... there's a CR branch that hasn't had updates in month
... there's tons of action in master
... there's tons of tests in master branch for canvas, but they don't work
... the tests in CR branch work
... in concerned about how this test suite which will last for many years converges w/ our plan to get the spec to REC

darobin: i agree
... the html testing TF
... should focus on getting to REC
... contributing to the broader thing, but not getting lost in it completely
... i wasn't aware the canvas test suite was broken

krisk: testing wants stuff to be automated
... we made canvas automated w/ TestHarness.js
... but we're churning it

darobin: you should raise a bug on that
... we are saving time by making them automatable

krisk: if we're just trying to say that <canvas> works and we're done

<CyrilRa> silence

MikeSmith: ms2ger made automation for <canvas> testing

<krisk> Here is an example http://www.w3c-test.org/web-platform-tests/master/2dcontext/path-objects/2d.path.arc.angle.5.html

[ paulc will carry mic around for the next half hour ]

<rubys> http://dev.w3.org/html5/decision-policy/public-permissive-exit-criteria.html

bryan: we should clarify focus on the spec

<krisk> This is in the master branch (doesn't work)

bryan: which section needs tests
... that would help Bin (Hu) go through the spec
... to decide which parts need testing
... there's a need to get down to the next level

<krisk> In the CR it's working http://www.w3c-test.org/web-platform-tests/CR/canvas2d/path-objects/2d.path.arc.angle.5.html

bryan: we'd like to focus the test writing
... which parts we should be writing tests
... which sections will have this `informal exit criteria`

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

paulc: this is the exit criteria

"For features that are well known to be widely implemented and deployed, and where implementations are believed to match the specification, the Working Group will assume effective real-world interoperability without testing."

paulc: i want this WG to start identifying those sections
... instead of building a massive infrastructure for html5

<CyrilRa> mic

paulc: that will identify which in that bar graph need testing
... i was reading the text from the judgement level
... i'd like us to spend some time at this meeting

<chaals> [+1]

paulc: w/ the ToC of HTML5 and Canvas
... Accessibility
... mjs, i'll pile on on Video
... but someone will put up a hand "in section .2 there's this feature i tried the other day"
... ah, ok, now we're getting the exception list
... to tell the testing people "we need a test there"
... i don't care what they do
... but we need the interoperability results
... "here's a test, MS, you don't do this the same way as Google
... we need to figure out if the spec is wrong, if you're wrong, if they're wrong
... of if something else is wrong"
... i agree w/ darobin, we won't get to the humongous test suite in time
... w/ the task ahead of us

darobin: we [w3] will get to the humongous pile, but not this group
... there's another group that wants to do that, but not this group
... the two are related, which is why i wanted to present the context

tantek: Tantek Celik, Mozilla

<plh> --> http://www.w3.org/2013/04/test_plan2.html W3C open Web Platform testing plan

tantek: there were large parts of CSS we thought were widely deployed and interop
... e.g. Margin collapsing
... in CSS1
... while developing the test suite for CSS2.1
... we thought things were widely implemented and deployed
... unless you think browsers are better implemented than CSS
... i'd challenge the assertion than the belief

krisk: thanks mjs (for yielding)
... back to darobin 's report
... going from the spec, section by section
... some are "this is just a definition"

darobin: this has been updated since the first version

krisk: in "infrastructure", there are a bunch of definitions
... a good thing to recognize

mjs: the point i'd like to make is that
... as the w3 process is set up
... getting to the REC stage
... the final stage of the process
... has a couple of different purposes, w/ different goals
... 1. is test suite driven and interoperable
... 2. is to prove that a specification is truly ready and should be referenced
... 3. is the w3c patent policy starts applying
... until that point, the policy is at best informal
... this leads to a tension
... between wanting interop
... and wanting the patent policy and getting people to "use this thing"
... part of the reason for the informal interop bit
... is to allow for the second to parts
... i don't want to downplay making a comprehensive test suite
... but it does make sense to prioritize portions for the test suite
... even though i agree on roughly interoperable bits
... there are bits that are slightly complicated
... saying "html5 is so much better than html4" is worth doing
... and not waiting too long

paulc: darobin, if this WG could identify areas that need testing, that would be useful

darobin: yes

<bryan> +1

paulc: and areas where this group doesn't think need testing
... that would be useful
... and work to identify qualitatively, interoperable, independent, implementations and judgement level

chaals: what mjs said, we think it's important to ship this spec
... we expect we'll find more bugs
... we will want to improve stuff

<plh> --> http://www.w3.org/2013/04/test_plan2.html W3C open Web Platform testing plan

plh: the test goal of this WG is different than the other test group
... a point i made to the testing team
... is that the HTML WG testing group will go for the minimum
... the goals are different
... even if the goal of the testing project is valuable
... to push HTML5 to CR
... i pasted a link by tobie for what we think for the testing project
... it's what we sent to our ...
... people are welcome to provide feedback
... this is wider than the scope of the HTML WG

Travis: the chart is good
... now we're trying to transition to defining what the WG needs to do for testing
... i'd like to focus the quantitative bits on our goals

paulc: this topic isn't over
... i'd like us to seriously consider using the time we have tomorrow
... to use qualitative judgement
... not sure if we should do it as the group as a whole, or crowd-sourcing (breaking up into smaller groups)
... you should expect we'll spend some time tomorrow
... i'll return to the agenda

Usage of Github and branching (Kris)

paulc: did you make your point?

krisk: the effort gone
... into setting this up in github, could go on forever
... is that where the CR branch come into play?

darobin: yes

krisk: so all changes there?

darobin: no
... github repo has 2 branches
... 1. master - where everything goes first
... 2. cr branch
... - designed as a subbranch
... people interested in maintaining cr cherrypick

paulc: does that apply to Canvas and others?

darobin: yes

krisk: also for webapps?

darobin: idea was webapps would do the same thing
... but not our problem at all

krisk: for a day or two

chaals: we're following the html wg down the github rabbit hole
... w3 signed up for a decade long project
... w/ github
... you're committed to making sure it stays alive?

darobin: we're committed

krisk: the master branch
... e.g. for canvas
... wanting to avoid unnecessary churn

paulc: who is the person responsible for the cr branch in github?

darobin: probably me

paulc: you, or the testing tf, or ?

krisk: anyone part of w3 w/ pull privs can

darobin: so far we've been working on the assumption that anyone willing to do work was welcome to do the work
... i was working on CR, but i haven't in a while
... but we don't have someone specifically responsible

krisk: the TF could
... changes at TPAC, and moving to github
... html needs to move forward

paulc: what about test results?
... if i'm an indivual
... or a company
... and trying to decide if i want to use the tests
... what's the setup to using the tests?

darobin: if you go to w3c-test.org/web-platform-tests/ there's a way to run the test suite
... you can check out the test suite
... we'd like implementors to use the test suite directly in their CI systems

krisk: it's in github, but it's synced to w3c-test.org

paulc: so i load this, and click this, and click this

krisk: and you click a .html file
... "you passed!"

darobin: it's missing straightforward navigation
... great browser, it supports document.title

paulc: on criteria in exit criteria
... the exit criteria testing requirements need to be publicly available
... w/o that, crowd-sourcing wouldn't be possible

<chaals> q

paulc: i've been in groups where the interop requirements were confidential
... krisk any points on github/branching?

krisk: action to make sure that it's clear
... what's to do

paulc: action on Testing TF to make organization of github test suite is documented and clear?

krisk: correct

<rubys> action on krisk make sure that the organizational structure of github test suite is well documented

<trackbot> Error finding 'on'. You can review and register nicknames at <http://www.w3.org/html/wg/tracker/users>.

paulc: let's skip: Review of which parts of HTML5 pass the "passive exit criteria"

<rubys> ACTION: krisk to make sure that the organizational structure of github test suite is well documented [recorded in http://www.w3.org/2013/04/23-html-wg-minutes.html#action02]

<trackbot> Error finding 'krisk'. You can review and register nicknames at <http://www.w3.org/html/wg/tracker/users>.

<rubys> http://intertwingly.net/tmp/wgtrends.cgi

<rubys> http://intertwingly.net/tmp/wgstatus.html

<Zakim> chaals, you wanted to raise the question of testing beyond the browser implementations

chaals: there's testing for browsers
... but browsers are not the web
... there's one of the pieces of the web
... people need to create stuff
... i don't see that all in the plan
... that seems like a failure
... quite happy w/ "testing of can you do this is anecdotal"
... saying "browsers will implement this code as specified"
... without saying "people will produce it as specified"
... is a problem

paulc: how would we tackle this problem?
... if you made this point when we were discussing our exit criteria
... would we have changed them?

chaals: i did raise it then

[ laughter ]

<rubys> ACTION: on Kris Krueger to make sure that the organizational structure of github test suite is well documented [recorded in http://www.w3.org/2013/04/23-html-wg-minutes.html#action03]

<trackbot> Error finding 'on'. You can review and register nicknames at <http://www.w3.org/html/wg/tracker/users>.

chaals: it's about also looking at authoring systems and usage workflows
... everything has been done

<rubys> ACTION: Kris Krueger to make sure that the organizational structure of github test suite is well documented [recorded in http://www.w3.org/2013/04/23-html-wg-minutes.html#action04]

<trackbot> Created ACTION-226 - Krueger to make sure that the organizational structure of github test suite is well documented [on Kris Krueger - due 2013-04-30].

chaals: i'll type a comment

<chaals> chaals: We have a lot of testing oriented toward browsers. But (like accessibility testing that goes beyond "simple" browsers) we haven't talked about other parts of the infrastructure - processing systems, authoring systems, content management and maintenance tools. If these don't produce what is in the spec, it doesn't matter what browsers do since they won't be processing that kind of content

<chaals> ... so I think it is important that we remember the rest of teh infrastructure in testing

<inserted> [The search engine and other processing implementations of microdata are an example of important but non-browser implementations, and on the other side so are code generators which actually create microdata e.g. for schema.org]

Status of HTML 5.1 and Canvas open bugs

paulc: microdata fell steeply

darobin: looks steep, but it fell from 9 to 1

paulc: when we appointed the editorial team last fall
... we had 480 bugs
... i think the editorial team quickly got rid of the spam
... when people typed the home row
... down to 420
... and since then, we're down to less than half
... we still have a bunch of important bugs
... bugs that might impact HTML5 or Canvas CR
... not clear what the situation is
... we need a downward trend
... and editors need to understand how to balance editing and fixing bugs
... darobin ?

darobin: thinking about that
... want to go through the buglist and mark absolutely must be fixed for CR

paulc: maybe it'd be useful if you did that
... we could add another histogram of that
... to see our flight path of zero bugs to cr

<rubys> ACTION: robin to give us a clear indication as to which html5 bugs apply to CR due in one month [recorded in http://www.w3.org/2013/04/23-html-wg-minutes.html#action05]

<trackbot> Created ACTION-227 - Give us a clear indication as to which html5 bugs apply to CR due in one month [on Robin Berjon - due 2013-04-30].

paulc: let's do that, on darobin on behalf of the editorial team
... and on the canvas editors?

cabanier: i think there are like 6

paulc: should be very easy

cabanier: i think they're all for the next version
... there's one we're going to remove
... hit regions, that changes an example

paulc: darobin if we can get that in the next month

darobin: yeah yeah

paulc: also, based on the editor's meeting
... it isn't appropriate for someone to file a bug and wait 6 months for a response from the editors
... someone needs to triage incoming bugs
... comments from editors?

Status of Features at Risk (more, less?)

paulc: suggested at last week's WG meeting
... that we might look at Features AT RISK
... this is the status section from the html draft
... looking at this

<glenn_> <h2 class="no-num no-toc" id="status-of-this-document">Status of This document</h2>

paulc: there's a lot of history here
... anyone have comments on these items?
... App Cache was added AT RISK because of talk of an App Cache v2
... I believe from TPAC was that this would be done in WebApps
... chairs had an offline discussion
... chaals, i don't think you got yourselves suitably rechartered

<glenn_> http://www.w3.org/TR/html5/#status-of-this-document

chaals: we believe that work is covered by our existing charter
... we'll check again
... if it isn't, we'll recharter

darobin: WebApps has a "get out of jail for free"

chaals: it isn't free

darobin: simply by notifying AC

chaals: a bit more complex than that

darobin: to take things that were worked on by HTML

chaals: it's an admin discussion
... between chairs and w3 and AC

paulc: will you discuss AppCache v2 this week?

chaals: yes

paulc: what did we do about <hgroup>?

chaals: it got kicked out

paulc: anything else to take out

plh: or add to the list

paulc: not sure how to add to a CR at risk list

rubys: we seem to think that API for Microdata is at risk

darobin: it's in microdata

paulc: anyone know what the cite= / bug 18915 thing is?

mjs: spec has a requirement that if you use cite= that the UA has to have a way to get to the url
... great wishlist, but never implemented

chaals: implemented in rare places, but yeah

paulc: not seeing further actions

<Zakim> MikeSmith, you wanted to ask if we talked about style@scoped

MikeSmith: we have two style@scoped implementations

paulc: i'll ask darobin and the editorial team
... we're talking about heartbeat documents for 5.1
... do the editors think it would make sense to publish a heartbeat of the CR?

darobin: we could
... not sure if there would be extreme value in it

paulc: if we did a heartbeat, then it would be useful to update the status
... to note that it's unlikely for the feature to be dropped because we saw implementations
... what would cause us to do a heartbeat for the CR?

chaals: a handful of important changes
... taking <hgroup> out of the spec
... @ Yandex, after they struggled through the badly written English in Russian
... and then told them that it changed

paulc: we have dropping <hgroup> and adding <main>
... anyone in the group who think that's enough to trigger a heartbeat?

chaals: what's the cost of a heartbeat?

darobin: grumpy editors

tantek: question i'd ask
... is any features that were dropped or changed were at-risk?
... if they were at-risk, then i'd see no problem w/ a heartbeat

paulc: <hgroup> was at risk
... but <main> was added
... we know we're going back to LC
... <main> is in 5.1,
... we're folding 5.0
... but we were going to publish a NOTE
... but plan 2014 permitted extensions to be folded in

glenn_: what do you mean heartbeat of a CR?
... a new CR?
... experience in other WGs
... if you make a substantive change, you need a new CR, doesn't mean going to LC

tantek: my preference is to issue a new CR
... i don't think that's supported by the CR process

paulc: we've issued WDs saying they were updated versions of CRs in other WGs

chaals: i'm working on the process document
... tantek, your point is noted

glenn_: changes Silvia has made for Text Track

paulc: were those changes in 5.0 or 5.1?

glenn_: one specific change was made to 5.0
... most changes were in 5.1
... one of the changes was going to be backwards incompatible
... so she made one change to 5.0

paulc: where / when was this discussion?
... Silvia was trying to abstract out to the extension spec

<plh> one can udpate a CR

<plh> the Process allows that

paulc: the portion for captioning

Janina: longdesc is obsolete in CR
... what's the status?

darobin: we have an open bug
... i haven't removed yet
... but i will, it will happen

paulc: another change to CR?

darobin: yes

paulc: thank you janina

<glenn_> http://lists.w3.org/Archives/Public/public-html/2013Apr/0063.html

paulc: people said earlier, their bar would be different by kind

darobin: this is moving a had to be supported out of obsolete

paulc: isn't that what Silvia's proposal was as well?

darobin: possibly

<glenn_> glenn: see above link regarding possible change (or need to change) html5.0 re: WebVTT features

Moving Image Description Extension to Last Call and plans for re-integration with HTML 5.0 (A11Y TF) [longdesc]

chaals: we have this spec
... the spec is HTML Community Description Extension
... we have FPWD
... we've described longdesc
... we have outstanding
... we expect to go to LC

janina: June 11

chaals: the thing according to the timeline of the patent policy
... we expect 150 days after FPWD, that we'll be done
... the question of integration into HTML -something- is open
... we haven't had nor sought agreement to integrate into html
... we figured we'd think about that more
... when the spec is actually finished
... when we'd actually gotten all that
... when the thing is ready
... whatever version of HTML is in the timeline in the point of process

paulc: re: what Janina brought up
... do you need the change darobin pointed to when you go to LC?

chaals: we don't need it
... but we'd like it to be made
... it isn't time critical

paulc: just wanted to understand if it's a hard linkage

janina: no

paulc: do you need help from the WG on the 11 bugs?

chaals: yes, i'm supposed to close 9 on thursday
... the way the TF works
... we propose resolutions
... at meetings, w/ a week delay since not everyone goes to meetings
... there are 2 bugs left

paulc: when you go to LC
... is that a CfC between PF and HTML WGs?

janina: I expect

chaals: yes

paulc: you're effectively giving a Time Table to the WG and people who read our notes
... that approximately in June
... to see a CfC
... since the TF owns the spec and does the work
... the TF will propose a Draft LC WD
... that would go to PF and HTML WG for CfCs
... and it would be published jointly by the WGs as the extension spec
... is that fair janina?

janina: yes

paulc: this is an example of Plan 2014 working
... when we first proposed this, a number of people were nervous
... and suspicious
... this is an example of Plan 2014 at its best
... only thing better is if we actually fold it back in

chaals: from my perspective, so far so good

janina: +1

paulc: experience as chair, best thing to do is recess/adjourn early

rubys: lunch is out there

paulc: please gather before 1pm
... topic will be MSE

[ Lunch ]

Media Source Extensions (MSE) (Media TF)

<gitbot> 01[13html01] 15rubys pushed 1 new commit to 06feature/whatwg: 02https://github.com/w3c/html/commit/03feebf25072ba37ee7095da756a8641b920f51f

<gitbot> 13html/06feature/whatwg 1403feebf 15ianh: [giow] (0) ImageData objects now expose an explicit pixel density, enabling them to be converted to BitmapImage objects correctly....

<SteveF> MikeSmith: http://www.w3.org/wiki/HTML/W3C-WHATWG-Differences

<gitbot> 01[13html01] 15stevefaulkner pushed 2 new commits to 06master: 02https://github.com/w3c/html/compare/dab1a6912807...dd337bd21b90

<gitbot> 13html/06master 1418097b2 15steve faulkner: tweaked aria-valuetext translatable conditions

<gitbot> 13html/06master 14dd337bd 15steve faulkner: Merge branch 'master' of https://github.com/w3c/html

paulc: in HTML WG, we have a Media TF that's working on MSE and EME
... at TPAC last fall, we spent probably 2 hours going over individual bugs
... I humorously commented that Google was telling Netflix how to build their service
... and Netflix was telling Google how to build their browser
... I got feedback that we had made good progress
... we don't have that many bugs
... we had a couple of topics
... open bugs, and getting MSE to LC

<paulc> MSE bugs

paulc: based on what worked @TPAC in Nov
... my principle is that we step through these bugs
... you tell us what you know about them
... tell me what to do

acolwell: Aaron Colwell, editor of MSE
... bug 20760 - defining interface for quality metrics
... adrianba had a proposal
... this is a subset
... i'm not sure of current status

adrianba: we want to discuss this
... Adrian Bateman, Microsoft
... we're getting close to agreement here
... couple of minor things
... reflected towards the end
... we proposed a method, rather than an attribute to make it clear you'd get a new object each time
... it's possible that the application could remember the timestamp for when it called the method
... but if there's latency, having the timestamp in the object makes sense
... we want to make sure all the data is from the same time
... not sure whether we think that just this data is sufficient
... it's obviously less than what we originally proposed
... which we thought was a good small subset
... it seems we're heading toward consensus with this limited subset
... if there are problems w/ implementation experience, we can change

acolwell: how should we proceed?
... i can live w/ the timestamp
... i don't strongly object
... the framerate i think you can derive
... jitter, i don't know

adrianba: i'm fine w/ leaving out those data values for now
... i'd like to see
... do you agree a method conveys more clearly than an attribute?
... i think people assume a value from an attribute they assume it's constant

acolwell: i know the `buffered` attribute on a MediaElement says it's a new object each time
... not sure about elsewhere

paulc: you said you wanted an object

adrianba: i wanted a method to indicate it's a new object

acolwell: i was using the MediaElement as an example
... i'll take an action to incorporate those changes into the spec

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20760

jerry: total video frames, how is that?

acolwell: originally it was frames before decode
... theoretically displayed

jerry: these values convey intended framerate and dropped frames
... initially we had a proposal for frame jitter
... how was that resolved?

adrianba: feedback so far, we want to make this as simple as possible
... there's agreement on determining frames being dropped
... "how essential to applications is jitter?"
... there doesn't appear to be much support for jitter right now

<gitbot> 01[13html01] 15stevefaulkner pushed 1 new commit to 06master: 02https://github.com/w3c/html/commit/610e94d71afef8168a155903fb64261c3c0ab3a2

<gitbot> 13html/06master 14610e94d 15steve faulkner: remove hgroup from element list...

adrianba: we want to support things where there's consensus
... the question is can we make a case for jitter?

acolwell: my concern is was that jitter significant?

<bryan> jitter is an important metric especially in variable network environments

acolwell: will people understand which to use

paulc: you'll raise adding jitter later?

adrianba: rate

paulc: and later, we'll open a new bug and point back

<gitbot> 01[13html01] 15stevefaulkner pushed 1 new commit to 06CR: 02https://github.com/w3c/html/commit/5ebde5b9f609f00548800d882e0d8b346f8d789f

<gitbot> 13html/06CR 145ebde5b 15steve faulkner: remove hgroup from element list...

acolwell: adrianba, can we do "out of order" last?

paulc: do out of order out of order?

adrianba: sure

<paulc> Bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=21298

acolwell: this is the media primer bug
... i kept it open because they requested a diagram

paulc: adrianba, you sent an email
... saying that the TF was requesting chairs do a call for volunteers for a primer for MSE
... i responded saying i'd do that
... i haven't done that

acolwell: you were saying this bug would be resolved by someone writing a primer
... i could resolve this as later for the primer
... this shouldn't block getting to LC
... i wanted to see i can get agreement on that

paulc: proposal to resolve as LATER
... put it in later, or in a primer
... 21298 is resolved LATER, w/ possibility of inserting diagram later

<paulc> Bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=21431

acolwell: i believe this can be resolved
... i'm not an expert
... i believe glenn_ said the preference would be to have a reasonable behavior
... and not have to deal w/ overlapping text tracks
... i believe we can properly handle splicing of text tracks
... assuming we don't have to deal w/ overlapped ones
... the behavior is predictable if you have overlapped
... but it isn't optimal
... i plan to close this bug

paulc: how will you resolve this?

acolwell: WONTFIX

glenn_: does the current text cover text tracks that support/override the behavior?

acolwell: it doesn't

glenn_: i'd like to see that

acolwell: can you provide suggested text and location?

paulc: if glenn_ can give a target and non-normative text
... saying that the format of a Text Track might override that

<paulc> Bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=21536

acolwell: i think adrianba is on the hook to provide text
... this is about origin/data handed to MSE

adrianba: we um
... talked about this in the context of
... some of the other origin related questions
... there are some aspects of the video
... element
... that depend upon whether or not the source of the data is Same-Origin or not
... since MSE allows applications to append data to data they have access to already, into the media buffer
... that data should be considered same origin
... we think there should be a note in the spec
... to make clear that any operations on the Media element will be considered Same Origin
... and I just need to do the work

paulc: sounds like a proposal
... you'll write it up?

adrianba: it's assigned to me, i will

paulc: we're waiting on adrianba in order to resolve this bug

<paulc> Bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=21703

acolwell: this is non-contentious, i just need to add the text
... I just need to add `unrestricted` and then resolve FIXED

<paulc> Bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=21796

acolwell: also pretty trivial
... there's an issue box in the spec right now
... "we need to define error codes from append"
... but it isn't clear what we need to return
... we'll remove this until we get implementation experience

paulc: so this is LATER?

acolwell: no, i need to remove text pending implementation experience

adrianba: the spec calls for a Simple Event to be fired
... which has no way to convey additional information
... we included this issue in our original submission
... about thinking about a way to provide additional information about the error
... we got this far w/o finding a need for it
... so we propose to remove it
... the note is asking for consumers to explain what they'd need/why
... right now we just fire an event to say there was an error
... and then we stop

acolwell: sometimes the error will be reported via XHR

paulc: 21796 will be resolved FIXED by removing the issue box

<paulc> Bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=20901

adrianba: we talked about this on the call a couple of weeks ago
... this bug was originally filed because of the need
... when you're supporting transport streams
... to indicate if an Append() is based on where you left off
... or resetting to a different timestamp
... and the solution was to modify Abort() to indicate why you're stopping
... to indicate if an Append() is a continuation
... this combined with other changes
... means that ultimately we found ourselves in a situation where
... even for formats w/ embedded timestamp information
... you wouldn't be able to do an overlapping or out of order fragment
... w/o calling Abort()
... we found that when snapping to the latest snap test
... that the tests we built previously stopped working
... since the file format supported out-of-order fragments
... we weren't including checks to prevent that
... we think this is a valuable part of the spec
... thus this solution for transport streams was imposing an extra burden
... on formats that didn't require this capability
... ideally, formats that support out of order append
... would be required to take no additional steps

acolwell: it's more about no ambiguity of steps
... in the transport case, it's unclear if it's a discontinuity or an out of order append

<acolwell> https://dvcs.w3.org/hg/html-media/raw-file/default/media-source/media-source.html#sourcebuffer-coded-frame-processing

acolwell: step 7 here is the crux of the problem
... where we're detecting if the thing being appended is w/in a range of what was previously appended
... i'm guessing that when this got implemented
... which we haven't implemented in Chrome
... things broke because out-of-order was determined
... when it wasn't before
... we could make it optional for only transport streams only

markw: make it required for transport streams
... i'd like to support adrianba 's proposal
... the absence of this is one of the many reasons that MPEG2 transport streams are a bad solution
... which is why other formats are better
... i was surprised that this arrived as a result of the MPEG2 transport stream
... if you need extra hoops for MPEG2 transport streams
... then add it to your list of extra hoops

acolwell: does bob or the other cable people

BobLund: the motivation for this
... this is a response to MPEG2 transport stream
... which has a

acolwell: a discontinuity allows
... the timestamps to just shift
... you have to see the frame before
... if you do appends right on the boundary
... it's ambiguous if it's out-of-order or not
... the rule to fix this
... appends were assumed to always be contiguous
... if this happened, you always new the append was supposed to be adjacent
... the proposal is to make this only the case for transport streams
... for MPEG4-ISO and WebM
... there's no need
... the only effect would be that on transport streams, you'll have to call Abort() more often than for ISO/WebM

BobLund: you'd have to call Abort() when it's discontinuous?

acolwell: no, when you want to do an out-of-order append

BobLund: is there a way to signal when there is a discontinuity
... strips will know that

acolwell: i was under the impression that scripts wouldn't know
... in HLS you would

BobLund: i think that's alright

paulc: proposal is in
... in Section-3.5.7 Coded Frame Processing

acolwell: i need to look
... i need to figure out exactly where
... i'll put a note saying that for transport streams, the behavior is slightly different

adrianba: maybe we can agree here that we do want to change this model
... and make what's currently there not be a problem for formats that include timestamp data
... i have concerns that just changing step 7 to make parts of it optional
... using Abort() in this way seemed odd to me

<paulc> Step 7 in 3.5.7 Coded Frame Processing

adrianba: it doesn't feel like you're necessarily
... sometimes you call abort when you aren't aborting anything
... Abort() is normally for cancelling a pending append/remove
... here you're calling it outside of that to set some flag

acolwell: i think there might be more that needs to change
... i think there's certain state
... Abort() allows us to reset state
... if we don't use Abort(), we'd need to figure out the pieces of the state

adrianba: we could create a new method
... and have the bits move there
... and have it be a no-op for other formats

acolwell: i think there are a couple of issues w/ how Abort() is being used
... we need to figure out the right separation

paulc: do we know what we're going to do here
... adrianba, you were asking if we need a different method?

adrianba: i was saying i think it's more than making a part optional

paulc: so, acolwell, it falls in your court to come up w/ a proposal
... i believe that's the last one
... only other item for MSE is
... as we go to 0 bugs, do we feel we could do an LC?
... any time you do an LC, you have to ask "how long would that LC have to be?"

chaals: 3 weeks is the absolute minimum
... longer specs should have more

paulc: between 3 and 6 weeks depending on size of spec
... it could be 6 months for some reason
... the TF can make a recommendation
... we'd do a CfC at the WG level
... do you have an idea of schedule
... this is April 23, will we reach 0 bugs in May?

acolwell: yes

paulc: anyone in the room think once we go to 0 bugs, we shouldn't go to LC?

adrianba: i'd like to make a slightly different proposal
... historically trying to say we'll get to 0 bugs has been a good way to make things last a long time

[ laughter ]

adrianba: my alternative proposal is to say
... what we've done in this group is
... "we believe we're getting close to a LC"
... we have work to go and resolve them
... now is the time for a Pre-LC for WG members
... to make sure they've looked through it
... and filed bugs
... if people file bugs after that deadline
... those don't block LC
... the point of LC is to get bugs from outside the WG
... but we're likely to get bugs from inside the WG
... we'd commit to resolve bugs filed before the deadline before going to LC
... and others as part of LC

<Zakim> chaals, you wanted to say exclusion period means 90 days between LC and...

chaals: shortening LC period doesn't necessarily help you
... keep the patent exclusion period in mind

janina: you can start the patent exclusion period sooner

chaals: it's necessarily from LC

acolwell: i'd like to do it as quickly as possible
... we made progress
... i came here a year ago and proposed this spec
... i'd like to keep this pace

paulc: where's this in the Process document, chaals ?

chaals: it's in the Patent Policy

paulc: adrianba 's suggestion is good
... adrianba 's asking for
... Chairs to send out a notice to WG
... "we're getting close to wanting to go to LC in MSE"
... "we're declaring an X-week pre-LC period -- bugs filed during that period will be dealt with before LC"
... "any bugs filed after that period will be dealt w/ during LC"
... it sounds like a 3-4 week period for the X-week
... i'll take an action to take an action to discuss that w/ my cochairs

adrianba: yes

Encrypted Media Extensions (EME) (Media TF)

paulc: the Accessibility people had a topic they wanted to discuss

[EME] Encouraging alternate media to be in the clear when primary media is encrypted (A11Y TF)

paulc: would someone from A11Y TF like to introduce the topic?

janina: sure
... the question is
... do we need to encrypt/drm protect/etc
... the various alternative kinds of media that supplement Video/Audio
... in the TF, we've canvased around the Group
... people who create Captions, Described Videos
... if you've read our documents, you'd know we're contemplated other alternative forms
... e.g. a parallel sign language track would cover more cases
... the question is that "does this need to be encrypted?"
... no one seems to really need that
... no one seems to have a UC/need for that
... then, if we go w/ unencrypted content
... how do we make sure that if you don't do so, you won't
... history shows that
... once you can, people check the box to encrypt
... which presents accessibility issues
... which we should probably avoid unless you need to

<paulc> rrsagent prepare the minutes

janina: i'd like to ask JF_ to speak
... i know he has a contrary view

JF_: the issue is
... not whether they can/we can
... but whether descriptive audio/descriptive text are encrypted
... they can be mixed in
... you have content A which is unencrypted
... but you have a secondary provider which might want to license additional content B
... and secure their additional content
... i'd like to tease this out w/ the technical guys
... to see if this were a problem
... if we have two streams from different CDMs
... like janina, it isn't like we have definitive answers
... but we have questions to the floor

Mark_Vickers: we're talking about transport formats
... older formats
... captions in the older standards were in band
... if things were encrypted, it was all encrypted
... the import thing is
... not whether it's encrypted
... but whether it's brought out through the standard Text Track APIs
... then it doesn't matter if it's originally encrypted
... i don't believe we have a mandate in the spec that says you have to do that
... you have to make Tracks
... there's nothing that mandates that the stuff comes out

markw: for Netflix, we don't encrypt Captions tracks
... we don't see any reason to
... or reason why we'd need to in the future
... for this spec, i'd advocate not doing additional work
... w/o requirements
... i don't think we have support/needs for CDMs rendering captions

chaals: i filed a bug on EME
... for the case JF_ outlined

<joesteele> +q

chaals: there are third party services that do captioning/description
... i know of services that do it

<paulc> Charles bug on tracks: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21741

chaals: i can't think of a service that charges for it
... actually, no, i can.
... if they're charging, and if you have an encryption api
... i'd expect them to want to use it
... i'd expect the people wanting to help people w/ disabilities wouldn't be able to

JF_: because of the possibility of this ... that it could happen
... between a rock and a hard place
... if the answer is that if it's very easy, very difficult, or something between
... that would help weight what to do
... if people say it's a 2 to fix (1..10), v. if it's a 8
... i'd like to understand how hard it'd be to fix
... i'm just concerned it's lingering out there

adrianba: the reason we chose not to try to solve this problem in the first release
... was it wasn't entirely clear how we should try to think about this
... because of support for presenting video+audio frames
... typically a UA that would process encrypted captions
... would have to have access to the captions
... we have a bug 21569
... which talks about the consequence of having Encrypted data in the media element

<MarkS> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21569

adrianba: talks about not being able to read data from a <video> element
... e.g. if you have encrypted <video> and you use the <canvas> draw api
... we have a bug to add info to the spec to highlight that case
... it puts the onus on the consuming api
... to handle cases beyond Cross-Origin
... to handle the error path when you don't have access to the media data
... in the absence of the api
... Text Tracks either work or don't
... if a particular app doesn't mind
... it could be seemless to the app
... an app could take in band encrypted captions
... apply it to the video
... but not make it available to the text track api
... the api could not work if the UA doesn't allow access
... i don't tihnk we need to provide for this explicitly in the spec
... once we gain more implementation experience

JF_: you're talking about Text Tracks, what about Descriptive Audio

adrianba: we believe we have support for multiple Audio streams

JF_: in that UC, your video is encrypted w/ scheme A
... and your audio is encrypted w/ scheme B

<gitbot> 01[13html01] 15rubys pushed 1 new commit to 06feature/whatwg: 02https://github.com/w3c/html/commit/f57d22e461085c6b27e05580ebbd1dcc8e72dd54

<gitbot> 13html/06feature/whatwg 14f57d22e 15ianh: [giow] (2) Add bitcoin: to the URL scheme whitelist, by request. It's more or less like mailto:....

JF_: will that work

chaals: and you don't see that's critical today

adrianba: i don't think we need to change the spec to satisfy the requirements

BobLund: seems like there are 2 situations
... one is when the tracks are encrypted
... and one where they are not
... it seems like it's up to the CDM to handle embedded encrypted tracks
... for the non-encrypted case
... it seems we need to specify how those are exposed by the UA
... the assumption is that normal audio/video tracks are made available in a standard way
... i don't think we can leave it up to the implementation to decide which tracks are available

janina: back to JF_ 's point
... i think we have a terminology concern here
... alternative media might be Audio, or Video, or Text Track
... not necessarily one or the other
... both are possible
... how to make it visible
... we ask for quite a lot in UA requirements
... we don't want to just make it visible
... we also want to control
... font color, background, size, portion of resource
... i'm really concerned if we start by worrying about encryption and what can/can't be exposed
... just because we might need it
... we're talking about the current version of the spec
... not the last version
... if we don't have demand for it
... why focus on it right now
... we have lots of requirements right now
... seems they're more important

ddorwin: you're worrying that unencrypted text tracks might not be made available during encrypted playback
... i believe it's implied that they would be available
... i don't know how we can
... i think we should discourage encrypting these tracks
... the biggest concern is that it will be hard to be compatible w/ a lot of platforms
... if someone wants to encrypt, they can do out of band traps
... and use WebCrypto for the same level of protections

mjs: question... maybe someone knows the answer
... maybe people who know more about media production
... in DRM production on Web today
... w/ plugin today
... are captions today encrypted?
... if they aren't encrypted today
... i'd think there's very little demand for HTML5 solutions
... and perhaps not to be supported

glenn: in encrypted transport of classic format
... it's encrypted
... in other forms, it's likely not to be
... except for the third-party encryption case

joesteele: when we have encrypted content
... we duplicate them and send them out of band in unencrypted form
... on a world-wide basis, i'm not sure if everyone is doing this

chaals: my impression is that there isn't a huge amount of alternative/extended content being encrypted
... a concern i have today
... is original UC
... the point of being able to encrypt content is that content providers have it as part of their business model
... it seems odd to say that a content provider has the right to do this
... but a disability provider doesn't have that right
... it seems back-ass-words way to do

JF_: what chaals said
... that we don't have demand now is great
... but that door seems really wide open
... too often, A11Y is chasing after the bus has left

CyrilRa: at XXX we're aiming at supporting all 3 modes
... embedded in the video

<CyrilRa> sorry about that… We are embedding CC within video

<CyrilRa> hence being encrypted

chaals: and thus encrypting them?

<adrianba> that assumes that it isn't feasible to do this - my assertion was that the spec doesn't need to change to support this - if there are specific changes someone thinks is needed then that should be proposed concretely

<ddorwin> CyrilRa: What container?

joesteele: w/ our DRM, we support encrypted text data in the streams
... judging on the number of bugs in the area

<CyrilRa> MPEG2-TS and MP4

joesteele: i don't think anyone is using it
... because i don't think my code is bug free

<CyrilRa> using HLS and HDS

joesteele: people use 608/708 data, captions encrypted because stream is encrypted

paulc: so you're doing the opposite
... of markw

<ddorwin> CyrilRa: AFAIK: You don't need to encrypt the all streams in a fragmented MP4.

joesteele: we're not doing it

paulc: someone using your information could do it

joesteele: correct
... if we were to provide an API for the CDM to extract that information

<ddorwin> (Not sure about HDS's requirements.)

joesteele: then i don't see the point in encrypting it
... someone said you could use WebCrypto and it would be just as secure
... i'd agree w/ that

markw: we don't encrypt the captions and don't see the reason to
... for audio/video assistive content
... i don't think we have many

<joesteele> s/I don't think anyone is using it/I am not sure it is being used/

markw: for captions, if you really want full DRM, you'd be asking the CDM to decrypt and render
... that would be a big additional requirement on the spec
... the only encrypted caption is whether they're embedded in the transport stream
... MPEG2 brings a number of hoops
... if you're given a bunch of hoops and implementing APIs in CDMs
... or just pulling the captions out at the sending side
... I know which makes more sense
... the APIs don't exist in protected media pipelines today

adrianba: agree w/ what markw just said
... i don't think anything in the spec today prevents someone from doing it
... i don't think there's anything necessary to add to enable this capability
... if anyone has a concrete issue not covered by the spec
... i'd like to have it raised

paulc: as the queue is empty, i'll move along
... janina, and JF_, you asked for opinions on the current spec, and from content providers
... I think we've come close to meeting your initial goal

JF_: hearing it isn't a huge fire
... i'd like to say thanks to the technical guys for lettings us talk through this issue

janina: i'm good

paulc: i'd like to remind people of what adrianba said
... when you're working in a TF environment
... the best thing to do is give it a concrete bug
... with a pointer saying "this is a bug here, please fix it"
... i'd like to encourage the A11Y TF to treat them the same way as you
... and i'd like to praise chaals for raising a bug to consider the issue

[ Coffee break ]

<paulc> test

Encrypted Media Extensions (EME) (Media TF)

paulc: two items
... deep dive into EME bugs
... - take an hour or so
... take a look at the situation of FPWD of EME

adianba: we'd like to start with consistent interoperable errors
... here is a UC for sites to report error conditions back to their hosts
... XXX

<ddorwin> adrianba: Call to ACTION: Review the content protection systems you work with, and collect the error codes that you might want to work with and report those.

ddorwin: we don't necessarily need to start w/ the existing bugs

<paulc> bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21798

ddorwin: not trying to force error codes - round peg square holes

paulc: 21795
... 16737
... 16617

Daniel_Austin: Daniel_Austin, PayPal
... i think we might want to provide a uniform set of status codes
... so users and sites can do diagnostics
... working w/ the WebPerf WG
... i posted a list of status codes to their group
... now's a good time to try to get them synced

paulc: has anyone else from the TF looked at this?
... I assume one of the parts of the TF will meet next week
... adrianba did you have a time table?

adrianba: we have lots of bugs

chaals: yesterday would be great

[ crickets and popcorn ]

joesteele: one of the error codes in there
... service error
... i shouldn't have gone through the existing errors
... but reported the actual errors we use
... one distinction in errors i'd like to make
... is customer service errors
... and cdm errors
... an end user error v. a customer's license server triggered failure

Daniel_Austin: WebPerf errors don't distinguish that

joesteele: we could distinguish errors by domain

Daniel_Austin: great suggestion
... i don't want an incomplete set of status codes coming out of perf

paulc: surely WebPerf isn't trying to make the one-ring-to-rule-them-all of error codes
... this is about the distributed web
... we want a spec that says these are some error codes

Daniel_Austin: we recommend the IANA registry for HTTP status codes
... we proposed an additional set of error codes for DNS errors
... and SSL errors
... and a set of errors for when a user abandons a page
... we haven't taken into account adrianba 's classes
... i don't want errors scattered across other specs

<ddorwin> Currently being displayed: http://lists.w3.org/Archives/Public/public-web-perf/2013Apr/att-0007/WebRequestStatusCodes4.html

paulc: what about "HTML spec" errors?

Daniel_Austin: if you'd like them available to the WebPerf NavigationTiming spec

<arun> https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html

Daniel_Austin: WebPerf WG has published specs for letting apps read counters from the browser
... navigation timings
... resource timings
... a new spec for error logging
... [for when something doesn't load from a CDN]

paulc: what's the link to the logging spec
... and how does it relate to what other WGs are trying to do

Daniel_Austin: i'll post a link to the spec
... it doesn't have much beyond the error codes

paulc: does this api simply return an error?

<ddorwin> Web Perf Error Logging spec: https://dvcs.w3.org/hg/webperf/raw-file/3298bdfd617b/specs/ErrorLogging/Overview.html

Daniel_Austin: it returns a list of error codes, and the objects that returned the error, and when
... there are two cases
... one is page load
... and another is for when the browser crashes
... we proposed a limited subset of the data
... that would be persisted
... that would be returned to the source site later
... that case is much more difficult
... we've decided not to specify a specific persistence mechanism

paulc: i'll end this discussion now
... we'll give you 15 mins tomorrow
... to give an intro to this spec and what it would mean to the HTML5 UA
... we have time in tomorrow's schedule
... i won't disagree w/ you
... that if the implications are close to what i said
... that this will have implications to what a UA would have to implement
... we'll talk at the end of today or tomorrow morning
... I tried to move of 21798
... and joesteele spoke on CDM
... which led to confusion on CDN
... so, to 20688

<joesteele> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20688

adrianba: i think we need to start w/ a bit of history, unfortunately
... we made a bunch of changes over time to the spec
... that brought us to the situation
... in our original submission to the WG
... we had this notion that during the acquisition of a license
... the CDM could force the browser to fire a message to the browser

[ long complicated and roundabout ]

adrianba: it's in the bug
... comment 2 in the bug says what i said
... we modified the API to use a more object oriented approach
... this means that, the way the messages/events are fired
... is a little different than we intended at the beginning
... we talked about it a few times on the call
... i summarized how we were thinking about the model
... but it isn't what's described in the spec
... this value is about one of the events
... keep "KeyAdded", be more precise about what it's for
... in my model, KeyAdded means "license acquisition is complete"
... think about it like progress events, it's like "load event"
... we're done loading, and you can move on
... KeyAdded isn't saying that a key is added
... but that the conversation w/ CDM is finished
... ddorwin said how do you deal w/ license renewal?
... sure you ended initial conversation
... but later during playback, you need to refresh the license
... and i suspect markw is going to comment as well
... and final comment on this, this model is related to some of the other bugs
... bug 19208
... - asks the question about when KeyMessage should be fired
... bug 16553

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19208

adrianba: - asks the question about a NeedKey event should be fired [an event before this whole process]

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=16553

adrianba: resolving this lifecycle is the largest unanswered question of the spec today
... that's the setup
... i was hoping people would weigh in w/ other questions we'd need to answer
... or suggestions about how we solve this

markw: i wonder whether we should take the approach
... of defining an explicit state
... and defining a variable w/ the state
... [a state machine]
... i think we could try to make that more concrete
... not sure what the states would be
... maybe 3, maybe 4
... i think that would make it much easier to talk about these things

ddorwin: even if we had a state for a session, there may be multiple message transfers in progress
... between a CDM and a License server
... you could have two renewal messages for different keys
... if you had a session to represent communication between a CDM and a License server
... you could have two in progress concurrently

markw: on that point
... i think we could take the approach of "what are all things a CDM could want to do"
... or "what is the simple state model that makes sense - and make CDMs work w/ that model"
... if the CDM wants to do two things at once, it constructs a message w/ two things in it
... instead of us imagining everything a CDM might want to do

adrianba: i think we need to support two or more pending transactions to license services
... no constraint on count to license server or transactions to a license server
... during decoding, you could encounter a need for another key from another license server
... we do need to have multiple conversations w/ a license server in flight at one time
... at the beginning
... at least, at some point, i had in mind that a session represented that communication
... you'd have one per conversation with a license service
... i think one of the problems is that we've slightly overloaded what we mean
... with a license service session
... and think we may need to break it into multiple models

<Zakim> ddorwin, you wanted to ask What specifically does having a "completed" state gain us?

<ddorwin> What specifically does having a "completed" state gain us?

ddorwin: you completed
... and send multiple messages
... what do we get from that

<ddorwin> Maybe states for an "initialized" and "has key(s)" would be sufficient?

<ddorwin> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20689

ddorwin: there's a bug about being told when you have nothing else to send to the server

joesteele: if i have a session open
... and i've done my initial exchange w/ a license server
... i do one, two, three exchanges
... and then my license expires, maybe this is key renewal
... the CDM knows i need to renew it
... can it just send a request
... is the app ready to accept that?
... if i have multiple sessions going on
... they can all be in this state at the same time
... they're all independent as far as the application is concerned

markw: to adrianba 's concern
... about multiple sessions
... and key messages
... we left it open for different CDMs to do it different ways
... you could file NeedKey
... or ...
... I think it's best to just pick a model

ddorwin: i think with CreateSession we said there was one way

johnsim: it's important that the states the CDM goes through
... that the application needs to know about
... are signaled/ known about by the application
... w/o a state diagram, it's hard for the application
... i think that's the missing piece
... wrt how a session is defined
... i think you can't let the way a session is defined be CDM specific
... because then an application won't be able to have a CDM agnostic behavior

paulc: you're saying something like what markw said
... abstract to the simplest number of cases
... and then a CDM may have to change its behavior to match our model

johnsim: two things
... 1. define the states any CDM will go through that an app needs to know about
... - CDMs can go through states an app doesn't care about
... for any state an app needs to know about, document it in a generic way
... providing events for the application
... 2. define it in such a way, that two different CDMs by different providers
... behave the same way wrt event pattern

paulc: if we take it at face value that you're right, johnsim
... then we need to know which states the App needs to know about
... what are those states?

johnsim: the current spec doesn't define those states
... as much as they're implicit in the event model

paulc: and that was markw 's point
... if we defined the points, it would help

adrianba: i like markw 's suggestion of having a state variable
... with clearly defined values
... and i think ddorwin 's suggestion of having
... what i described as Finished
... actually indicate "reached steady state"
... the proposal i sort of hinted at in the bug
... was to provide a set of events based on progress events
... idea would be, an event fires
... to indicate that the session was initialized
... "load start" equivalent
... what we have for KeyMessage would be the equivalent of "progress"
... and we would fire an equivalent of "loaded" for when KeyAdded was in the proposal
... to indicate that the session was established
... you may still get future key messages for renewal
... but the initial conversation was done
... i'm not sure we'd need to be explicit about Expired or some other reason for a Renewal

<Zakim> ddorwin, you wanted to ask What states do we need/care about? Do we need states if the application knows exactly what it needs to do for a given event? Rephrasing what I asked

ddorwin: it's currently stateless
... you get a key message
... get something from the server, pass it back
... works for initialized
... Otherwise, i like adrianba 's states

adrianba: one reason i think we need something like loaded

<ddorwin> What states do apps need/care about? Do we need states if the application knows exactly what it needs to do for a given event? Rephrasing what I asked earlier, do we need one of those states to be "closed"/"ended"? If not, then just responding to events may be sufficient.

adrianba: is one of the bugs i called out before

<Zakim> markw, you wanted to say how keyrelease fits into this model

markw: if we define a bunch of states
... and discover that the states are implicit from the message sequence
... we could leave them in or rip them out
... adrianba mentioned keyrelease
... in that state, if the CDM supports "proof of key release"
... then it's in the position to give you that proof
... and we define what happens for that state transition

paulc: doing a state transition model is important
... so that people can understand what's going on

markw: discovering if the implicit thing works or not
... is to be explict

joesteele: adrianba 's point
... there's one state needed that isn't implicit
... if a CDM already has a particular key w/o key exchange
... then you want the application to not wait to get a keyrequest message

<ddorwin> My summary of (my understanding of) Adrian's proposal:

<ddorwin> States: Uninitialized, initialized ("loadstart"), keymessage ("progress"), keyadded replacement ("loaded")

<ddorwin> I think the last three might be events. The first state is probably implicit.

<ddorwin> The keyadded replacement could be useful for a case where the CDM immediately initializes a session with existing material.

ddorwin: the events in quotes are video equivalents
... keyadded is already going to be renamed

paulc: we need to decide if someone is going to write a proposal
... someone writes a state diagram and shows if it maps
... and if not ...
... will someone do this?

[ paulc lists a bunch of bug numbers ]

paulc: there's probably a bug on key release
... adrianba, ddorwin, do you know the next steps?

adrianba: it feels like we've made progress in this discussion
... i think the editors have enough to get together
... to make a proposal back to the group

johnsim: one of the things, you already have a key
... e.g. from a store
... there could be a case where the app wants to force the CDM to make an acquisition
... a CDM could make a License server request
... but CDMs can also make a disk protected key
... some applications might want to force the CDM to get a new key from the License server
... if you support getting a key from the disk
... you need to give the app a way to specify if it permits using a key from the disk

adrianba: i'd like johnsim to file a new bug on this
... to make sure we don't lose it
... proposal i will then make in that bug
... maybe when the event fires to indicate that the session is loaded
... it's possible we want to provide some indication of how it got to that point
... e.g. if it did it through cached key material
... the application could do something

<ddorwin> alternatively, tag the keymessage to indicate "already in progress"

joesteele: specific case is renewing a set of entitlements before going offline

<markw> How about this: http://www.websequencediagrams.com/cgi-bin/cdraw?lz=dGl0bGUgQ0RNIFN0YXRlIFByb2dyZXNzaW9uCgpub3RlIG92ZXIgQ0RNOiBVbmluaXRpYWxpemVkAA8OLCBBcHA6IHRpbWUgcGFzc2VzAC0QSQAzCGFlZApDRE0tPgAtBWtleW1lc3NhZ2UKQXBwLT4AZAV1cGRhdGUoKQpvcHQAAyllbgCBBQ86IHJlYWR5AIEUFXBsYXliYWNrACQ-AD0QAIE4CmNsb3NlKCkAgjIQABIFAIFpFiAoa2V5IHJlbGVhc2UpAIF5FA&s=napkin

joesteele: if i'm about to go offline
... i thought about offline content long ago
... and decided not to file it
... because offline playback in the browser wasn't a UC under discussion at the time

paulc: offline entitlements are different, or just cover more time?

joesteele: cover more time

paulc: you'll be disconnected, and can't get a renew
... you'd say "give me one now", and it will last longer

johnsim: even in the live video case
... or OnDemandVideo
... you're playing content from the web
... you're allowing for local key storage
... the main reason why i felt it needed to be addressed
... i knew in general, such a UC is very common in DRM systems

<paulc> Bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=16540

johnsim: we shouldn't restrict what we're doing in EME to what we're trying to do now for OnDemandVideo

adrianba: this is one joesteele wanted us to talk about

joesteele: my concern with this
... the bug is confusing to read now
... about how you're supposed to use the key system
... 1. can we roll capabilities into it
... it was split out, and we decided not to do that in the key system
... 2. verisioning
... UC was to request a specific version of a CDM
... a particular version of a CDM may have a feature an earlier one did not
... a particular version of a CDM may have been breached
... - want to avoid using those
... i was thinking we'd register com.adobe.access and com.adobe.access.v{n}
... so we could request the latest one and the generic one
... does that make sense?

<adrianba> https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#key-system

paulc: is versioning mention in the bug?

ddorwin: you have to look at the spec

<gitbot> 01[13html01] 15rubys pushed 2 new commits to 06feature/whatwg: 02https://github.com/w3c/html/compare/f57d22e46108...31bbb5f68cbf

<gitbot> 13html/06feature/whatwg 14e2287ae 15ianh: [e] (0) Try to clarify use of the term 'expose' in the WebIDL sense....

<gitbot> 13html/06feature/whatwg 1431bbb5f 15ianh: [e] (0) Remove redundant requirements....

<adrianba> https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#dom-istypesupported

paulc: your proposal was appending something to example com.example.somesystem.1 and com.example.somesystem.1_5
... this is obscure being linked to this particular bug

adrianba: i pasted another link that talks about this
... joesteele was talking about isTypeSupported()
... the original design is that
... you could make a request isTypeSupported( com.example.somesystem )
... that would return true if the general system is supported
... if no, you wouldn't interrogate further
... if yes, you could ask about v1, v1.5
... i think the question raised in this bug is
... do we need to add
... text to the spec that describes this more
... gives greater guidelines
... is this pattern something that's actually needed
... or is it something down to the CDM?
... it's unlikely that you'd write code that follows this pattern in a generic way
... since the capabilities of different versions will be different across different systems

paulc: joesteele, is the system powerful enough to use in the way you want to use

joesteele: yes, it's probably overkill than what we'd want
... we could live w/ an explicit string match
... having browsers do this is more than we'd need

chaals: this code assumes linear progression
... and you want hasMinimumVersion()
... is that likely to be a pattern?

paulc: i'll take anything after version 3?

chaals: if IE3

adrianba: and the people that do, we're trying to shoot
... it's no coincidence that this is tied to the other bug about capability detection
... no coincidence that we'd park that bug until we decided on what we need to detect
... maybe we can say we don't need this sophisticated approach
... maybe we can push toward feature detection instead of particular versions

chaals: did you discover trying to push people to feature detection
... because people did version detection?
... are we opening up a way for authors to make mistakes early?

adrianba: maybe
... i'd rather try to catch it early than try to predict and get it wrong

chaals: i think i'd like to do the same

paulc: enough discussion on 16540?
... sounds like simple string matches
... if we aren't doing capabilities
... after that, you can use another mechanism
... next is 19009

<paulc> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19009

adrianba: we discussed this on a call
... the minutes didn't really
... describe a conclusion

paulc: these are the minutes in comment 6?

adrianba: yes, but it points to a not useful, but lengthy discussion
... conclusion i think we reached
... was that we should add a note to the spec
... that some implementations might require the media keys be attached to a media element before the event sequence would take place on a session
... this is somewhat tangentially related to the original bug
... i think that conclusion means that we're ok to
... follow the pattern we have right now
... make it so that implementations may throw an exception if they don't support media keys being shared across multiple elements
... that's likely for initial implementations
... important thing is that we need to add a note about requiring attachment

paulc: action?

adrianba: action is to edit the spec w/ the note
... just wanted to clarify that this is the next action
... and give people a chance to comment if they disagree

paulc: any last things to address?

ddorwin: 20335

<ddorwin> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20335

ddorwin: canPlayType
... supports "", "maybe", "probably"
... initially in MSE, we have isTypeSupported
... should we also return boolean?
... does anyone support canPlayType()s 3 states, none of which are true
... anyone have an opinion?

paulc: if we change it to a boolean, the probably case goes away?

[ maybe ]

paulc: what's the UC for Probably?

johnsim: Probably/Maybe concepts
... is ...
... you can't tell from media util you play it whether you can really play it
... it isn't just searching for attributes
... i don't see a case where any uncertainty should reside
... as to whether or not content is decryptable by that key system
... you don't know if the license server will honor the request for the key

ddorwin: we pass in the container as well

BobLund: canPlayType
... probably is meant to say "does the UA support mime type"
... whether UA can decrypt it is irrelevant to canPlayType

adrianba: i wanted to describe two alternatives
... spec has isTypeSupported as a boolean
... you use this method to answer
... "does the UA support decrypting content in this format using this content protection system"
... if the UA says "probably" or "maybe"
... and you add in the content type
... and key system
... might you get the same answer as canPlayType
... otoh, supporting canPlayType and isTypeSupported
... then a bool would work
... what does an app do differently if it sees maybe or probably?
... it's just going to try to play the content
... if you know definitively that it won't work, you probably try the next content
... but if you know it's potentially supported
... then you probably just try to play it

<ddorwin> There are probably less random formats to deal with in EME as well.

joesteele: we'd probably prefer a boolean
... yes it may fail
... it may mean it can't play that instance, but just that instance

paulc: hearing a bool pref
... anyone can give us an example of why it shouldn't be a boolean

joesteele: you ask about a mime type

paulc: and i can give you a mislabeled stream
... ddorwin you asked about this type
... did i get you an answer?
... and don't say "probably" or "maybe"

[ laughter ]

First Public Working Draft status

<paulc> http://lists.w3.org/Archives/Public/public-html-admin/2013Feb/0123.html

paulc: we asked about whether something was in scope
... eventually ruled it was in scope
... whether FPWD contained enough to be implemented interoperably
... we asked for clear and specific bug reports in Bugzilla by Feb 15
... once that was complete, we were going to seek answer from editors on how to proceed
... process bar for FPWD is fairly low
... when we reevaluate request to publish
... we'd only consider things based on bugs
... but no requirement of reaching 0 bugs
... TF received approximately 13 bugs
... in the window
... i provided a summary on the Media TF

<paulc> http://lists.w3.org/Archives/Public/public-html-media/2013Apr/0089.html

paulc: my first email goes over the history
... it's a bit hard to give concise status of bugs
... it's hard to handle REOPENed
... the respondent disagreed with being able to take a document to FPWD with bugs open
... some respondents have commented on everything as "i disagree"
... which makes it hard to have a dialogue
... for 20944
... - we left it open and proposed to add a SOTD
... i think we did this for 2 or 3

adrianba: 3

paulc: we believe there's technical merit in the comment
... but we don't believe it should stop us from going to FPWD
... we resolved several as WONTFIX
... i included link to bug and editor's response explaining why
... - which typically includes the link to the minutes
... here's one w/ needsinfo
... - which was reopened w/ no new info
... a couple were resolved worksforme
... - we took an appropriate action
... 20965 and 20966 were SOTD items
... one we resolved as a duplicate
... and one as later
... several of these bugs have been reopened by the correspondent on a regular basis
... even if the correspondent didn't change the status of the bug
... all of these bugs are attempts to characterize why not to do EME in the HTML WG
... there are more filed after the bug-window
... there are probably 4 or 5 more
... the people against this work being done in the WG
... when their current arguments fail
... they find new arguments
... the TF + editors have responded to chairs
... based on the bugs in the window to Feb 15
... i think it's germane for the chairs to review if the bugs have been dealt w/ adequately
... and decide if we can replay the CfC
... or decide if the document can be published

rubys: i don't think CfC is the right step
... we don't need Consensus per process
... having read the bugs, i don't think we have questions

paulc: i want to be fair to my cochairs and apologize to the TF
... this has been on my plate for a while
... i told rubys and mjs that i sent this after lunch
... the appropriate step is for chairs to take this under advisement and report back to the WG
... mjs, there's a lot of reading
... do any of the 3 editors of EME want to comment?
... did i summarize this accurately?

adrianba: yes, good summary
... we call out 3 of the bugs in SOTD
... two issues:
... 1. degree to which spec supports interop between implementations
... 2. issue around privacy considerations
... from discussions we've gone through these bugs
... i think we've made progress on privacy
... my suggestion for privacy is to add a section to the spec which is privacy considerations for CDMs
... people in WG asked if the current API would support some privacy related situations
... some of the cases I believe are already handled
... beyond guidance to CDMs
... which we'd add in an informative way
... does anyone see API changes necessary for privacy aspects

paulc: has that direction been reflected in the bug at all?

adrianba: no, we need to update the bug

paulc: that would be useful, if you could do that post-facto to this discussion
... chairs will use my summary as the response to the CfC
... and we'll get back to editors+TF as soon as possible

plh: if i heard chairs correctly
... we may not have a new CfC

rubys: statement i made, not a chair statement

plh: my concern is if it will surprise the group if we don't have a CfC

mjs: we have past precedent for CfC to publish a WD
... and having done a good faith effort, we said "with these addressed, it was ok to publish"
... if we wanted to follow W3 process
... we could have a formal vote

[ paulc reads from previous chairs CfC response ]

rubys: i sent an email on the 24th
... ~consensus is not a requirement for publication~

steve: are chairs saying
... there will be a FPWD

rubys: still deciding

steve: and that decision will not be a CfC?

rubys: my input is it probably will not be

paulc: it won't be public

wseltzer: Wendy Seltzer
... noting that the response to several of the bugs
... ~CDMs are out of scope for this document~
... several seem to be things people are complaining about
... are things required of CDMs
... but not things above them
... would it be ok for them to file bugs asking for CDMs to be brought into scope

<rubys> http://lists.w3.org/Archives/Public/public-html-admin/2013Apr/0053.html

wseltzer: this is requiring activity but not specifying it

paulc: i'd like to thank chaals for his leg-work

[ applause ]

adrianba: it's true there were a number of bugs
... commenting on CDMs being out of scope of the EME spec
... it's true that this is the design of the EME spec
... EME is designed to abstract away CDMs
... to provide a common api for CDMs
... and provide a common api for that abstraction
... W3 decided that such an API was within scope for the WG
... EME spec is a solution for the problem
... it isn't the only way to solve the problem
... someone who believes the full capabilities should be w/in scope
... may write the spec
... to try to address a spec that by design isn't in scope
... is essentially saying throw away the spec and start again

markw: we could add something to say what we mean by CDMs being out of scope
... we don't define the APIs that the CDM might support
... it has key messages, we talk about a state machine
... we say CDM is out of scope
... but we define a bit about how you talk to it
... it sounds like defining part of CDM

mjs_: re: what is exactly required for CDMs
... i think there's one bug left open
... with an issue note in the spec
... 20944
... EME sure do more to ensure CDM level interop
... there's been a lot of discussion in that bug
... many of the other bugs were roundabout ways to get at the same issue
... i think it's best of have one bug for that matter
... ---
... a more procedural issue
... 21016
... ClearKey
... - i don't care much about the bug actually
... our usual approach for LATER is to use only for "not this current version of this spec"
... i assume we'll have implementation experience by CR
... i'd propose keeping the bug open
... and having an implementation marker

chaals: instead of writing an entire spec from scratch
... they could propose a modified version of the spec
... which modifies the scoping
... if you modify the proposal for a tower
... to have the tower have an antenna on top

adrianba: could you start from EME and add in a CDM
... and remove the abstraction of CDM
... sure
... is that different from starting from scratch?
... i dunno

paulc: you guys are making it hard for me to recess by 5pm

chaals: if you want to make a smaller change to the scope
... then the difference becomes more interesting

paulc: no one has tried to ask about an extension spec to an extension spec

[ laughter ]

adrianba: mjs_ made the point that there's still a bug about part of this
... many of the bugs essentially raised the same point
... about interop
... between UAs
... and it's a valid issue
... the bugs wseltzer mentioned where CDMs were indicated as out of scope
... asked for essential design changes
... my position is
... if i were to solve for those bugs
... i probably wouldn't start w/ this spec

paulc: thank you Josh_Soref for scribing

[ Applause ]

paulc: do we need to retrace our steps with you?

Daniel_Austin: everything is locked at 5pm

paulc: and we're in a different room?

Daniel_Austin: yes, you'll be escorted to the new room like today
... please keep your badges
... there's a reception tomorrow

[ Adjourned ]

Summary of Action Items

[NEW] ACTION: Kris Krueger to make sure that the organizational structure of github test suite is well documented [recorded in http://www.w3.org/2013/04/23-html-wg-minutes.html#action04]
[NEW] ACTION: krisk to make sure that the organizational structure of github test suite is well documented [recorded in http://www.w3.org/2013/04/23-html-wg-minutes.html#action02]
[NEW] ACTION: on Kris Krueger to make sure that the organizational structure of github test suite is well documented [recorded in http://www.w3.org/2013/04/23-html-wg-minutes.html#action03]
[NEW] ACTION: robin to give us a clear indication as to which html5 bugs apply to CR due in one month [recorded in http://www.w3.org/2013/04/23-html-wg-minutes.html#action05]
[NEW] ACTION: sam to bring microdata proposals to the working group 1) terminate as a note, 2) take attributes to CR, 3) move to 5.1 [recorded in http://www.w3.org/2013/04/23-html-wg-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.137 (CVS log)
$Date: 2013-04-23 23:58:22 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/HTML Weekly Teleconference/HTML Interim Face to Face/
Succeeded: s/ok/ok, ruby,/
Succeeded: s/Topic: CR and Testing//
Succeeded: s/ohters/others/
Succeeded: s/re:/c. re:/
Succeeded: s|/|?|
Succeeded: i/think we can do Microdata first/Topic: Getting Microdata to CR (Editorial team)
Succeeded: s/See //
Succeeded: s/proces/process/
Succeeded: s/critera/criteria/
Succeeded: s/TestHarness.s/TestHarness.js/
Succeeded: s/`ben`/Bin (Hu)/
Succeeded: s/thatr/that/
Succeeded: s/../.../
Succeeded: s/master/master - where everything goes first/
Succeeded: s/-//
Succeeded: s/-//
Succeeded: s/-//
Succeeded: s/crowd/crowd-/
Succeeded: s|Topic: Status of HTML 5.1 and Canvas open bugs||
Succeeded: i/Topic: Status/[The search engine and other processing implementations of microdata are an example of important but non-browser implementations, and on the other side so are code generators which actually create microdata e.g. for schema.org]
Succeeded: s/ack//
Succeeded: s/sylvia/Silvia/
Succeeded: s/of/to/
Succeeded: s|MSE bugs; http://tinyurl.com/6pdnzej|-> http://tinyurl.com/6pdnzej MSE bugs|
Succeeded: s/XX/jerry/
Succeeded: s/XX/jerry/
Succeeded: s/to/in order to/
Succeeded: s/htis/this/
Succeeded: s/XX a bit/parts of it/
Succeeded: s/pre-LC period/pre-LC period -- bugs filed during that period will be dealt with before LC/
Succeeded: s/foliet/johnf/g
Succeeded: s/johnf/JF_/g
Succeeded: s|video/audio|captions|
Succeeded: s/encrpyted/encrypted/
Succeeded: s/BobLund/glenn/
FAILED: s/I don't think anyone is using it/I am not sure it is being used/
Succeeded: s/pulling it out yourself/pulling the captions out at the sending side/
Succeeded: s/stuff bugs/force error codes/
Succeeded: s/squareholes/square holes/
Succeeded: s/posed/posted/
Succeeded: s/68/88/
Succeeded: s/three/two/
Succeeded: s/not get/not wait to get/
Succeeded: s/want/- want/
Succeeded: s/neede/needed/
Succeeded: s/q//
Succeeded: s/15/13/
Succeeded: s/dialog/dialogue/
Found Scribe: Josh_Soref
Found ScribeNick: timeless
Present: adrianba chaals Jungkee_Song Bryan_Sullivan Jonghong_Jeon
Found Date: 23 Apr 2013
Guessing minutes URL: http://www.w3.org/2013/04/23-html-wg-minutes.html

WARNING: No person found for ACTION item: on kris krueger to make sure that the organizational structure of github test suite is well documented [recorded in http://www.w3.org/2013/04/23-html-wg-minutes.html#action03]

People with action items: kris krisk krueger robin sam

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)

[End of scribe.perl diagnostic output]