HTML -- 01 Nov 2012

<gitbot> [13html] 15rubys pushed 2 new commits to 06feature/whatwg: 02https://github.com/w3c/html/compare/ec5dd89bfb2a...fcca364e971a

<gitbot> 13html/06feature/whatwg 1417cedfa 15ianh: [giow] (1) Prevent a race condition between <video onerror> and <body onload>...

<gitbot> 13html/06feature/whatwg 14fcca364 15ianh: [e] (0) Clarify that 'directionality' applies to all elements....

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

<gitbot> 13html/06feature/whatwg 1442cafdc 15ianh: [e] (0) Match Selectors terminology better...

<paulc> F2F agenda topics: http://www.w3.org/html/wg/wiki/TPAC2012#Topics

<krisk> what conference is this?

<krisk> who is here?

<krisk> http://www.w3.org/html/wg/wiki/TPAC2012

<krisk> is the link to the wiki for Face to Face topics

Organization

<matt> scribe: Matt

-> http://www.w3.org/html/wg/wiki/TPAC2012#Topics HTML Topics wiki

paulc: Let's scan down the wiki, see what's on the list of topics.
... We're in Rhone 3. We also have Rhone 2. We'll see if we need it. We've arranged a separate IRC channel and call-in number for rhone 2.
... At the end of this session, I'd like to have all the TBDs filled in.
... I'm not sure if anyone other than Cynthia would like to join, but let's get this updated.
... I'd like to see the minutes posted on the wiki from the sessions.
... Coffee breaks are 10:30-11:30, so we'll break at 11. We could break earlier.
... And 3-4 in the afternoon. We'll have to decide when we look at the agenda how long each of the two days go.
... Break 3:30 and then a 90 minute session until 6:00.
... Topics: Email list organization, several bugs, four tracker requests, alt guidance and alt text, multilingual web group coordination (I talked to Felix and suggested tomorrow morning 9-9:30), i18n (30m slot next to multilingual if possible)
... Review of outstanding bugs for i18n

darobin: We do have a few bugs left, have to discuss them and move forward.

paulc: Please get the bug numbers and update them in the wiki.
... Media task force has been meeting on alternating Tuesdays. Encrypted Media Extension and the Media Source Extensions. Both have come with a detailed list of bugs on these proposals. The WG hasn't approved the proposals as FPWDs, but the plan would be to make as much progress as possible to flatten many of these bugs and get closer to a FPWD.

plh: I'd like to know the timeline for EME and MSE.

paulc: The WG needs to be rechartered and Plan 2014 has a timeline for 5.1 and 5.2, but if the charter could give a proposed timeline for EME and MSE, that would make the charter that much more complete when it goes to the AC.

[[+1 to discussing timeline for EME and MSE]]

paulc: Responsive image extension specs, this has been requested for day 1. There are people here for that that won't be here tomorrow.
... The EME and MSE would take up most of the afternoon, so there might be a natural ordering here.
... Evolving AppCache discussions in WebApps. They've suggested they might want to take over that work.
... Maincontent element extension spec.
... Completing ISSUE-204?

<cjones> cjones - present

hober: there are several interrelated bugs on the hidden="" section, which we'll probably address all at once

paulc: Next item is working group status. I sent the report that mjs, sruby, plh and I worked on for the AC.
... Could look at that and discuss what would happen in the draft charter. I don't expect this item to be big.
... Preparing for CR, already sent a draft to Director.
... Features at Risk, go over them, determine consensus amongst people in the room that we have the list correct or if there are items missing.
... We already have consensus on the CR exit criteria.
... Status of the CR WDs, will we see them before this meeting is over?

darobin: We do have CR drafts, have some changes like exit date and get them checked by people.

paulc: Chairs want to get to CR as quickly as possible. plh has a sharp stick in our ribs.
... Want to discuss these topics and know how quickly and when we can do a call for consensus on two remaining items to get to CR: items at risk and ??.
... There's an item on HTML 5.1 planning, with proposed new elements

MikeSmith: I've got a list that needs updating.

paulc: And then the status of the 5.1 WDs. We'll want editors drafts started at least after CR. And we need to discuss FPWD schedule for 5.1
... Any additions to the list?

MichaelC: I added to the wiki HTML 5 accessibility techniques. If anyone is interested in joining the Task Force, let me know.

paulc: Any other topics?
... None.
... Proposal 1: I've already seen interest in the media stuff.

matt: There's also the people from the Web and TV IG who are interested and not here (at AC, or not interested in rest of agenda).

paulc: Let's do that in the afternoon then in two slots.
... Break from 10:30 to 11. Lunch is at 12:30-2.
... 2-3:30 then break from 3:30 until 4.
... And the last session is from 4 until 5:30 plus or minus.
... Media folks, which session will be longer? EME or MSE?

adrianba: I suspect we have enough things to fill both of them, but I don't imagine we'll get through everything.

paulc: We can put them in any order then.
... I believe everyone involved in these would like to meet tomorrow to take the results of this meeting and move the specs along.
... We have two requests to meet tomorrow morning: multilingual web at 9 and i18n at 9:30.
... The responsive images folks had a request for today. I suggest we do that after coffee this morning.
... I believe our CR discussion is important.
... Let's do that tomorrow.

matt: Friday afternoon people start leaving.

paulc: Everyone put up their hand if here at noon, 3, 4… looks pretty good for the afternoon for quorum.
... Is that sixty minutes to do CR plh?

plh: Including features at risk? More than 60 minutes.

paulc: What about testing?
... It'd be good to have a report on testing.

Kris: There's been talk about the repository and combining it all together. Another item on how to publish test results, that's part of the 2014 Plan.

paulc: Less than an hour?

Kris: An hour is a safe bet.

paulc: Let's put status item along with CR item together.
... And we should talk about schedule for EME and MSE in that session so we can say tomorrow the schedule.
... What else is really important to get on the agenda?

Josh: The accessibility task force is meeting upstairs, please get in touch with me if you want to get involved.

paulc: Looking to the floor for nominations of the next important item.

adrianba: I don't think it'll be a long discussion, but the future of AppCache.

paulc: Art? Do you have restrictions on being here?

ArtB: I might be here tomorrow morning for a few hours.

paulc: 30 minute slot tomorrow morning for AppCache does that work?

adrianba: Works.

Cameron: HTTP request generation and enhancement. It'd be good to discuss with browser vendors in the room and get ext spec written with normative requirements.

paulc: Cameron, you won't be here tomorrow afternoon, so let's see what we have.
... Let's look at the 2nd day in the morning.

ArtB: I'm not sure I'm critical path for the AppCache discussion

henri?: We need a lot of time for that.

paulc: There may be a lot of overlap, but this group needs to express it's opinion.

mjs: We should survey this room to see if we need to have a longer session at all.

paulc: Let's do AppCache immediately before coffee and put ISSUE-195 into this slot.

cameron: Let's recap on the AppCache thing too.

paulc: That'll open the slot in the main room for Cameron.
... Nominees for other important items? We still haven't put testing anywhere?

Kris: Can we do that tomorrow?

paulc: OK, large room? So far we've been surviving with the one large room. Should we squeeze the agenda to keep us in one room?

MikeSmith: Best to have everyone in the same room if we can.

paulc: Testing for an hour in the 14:00-15:00 slot tomorrow.
... Lots of bugs in the wiki and ISSUE-204 as well. Anyone in the room want to nominate a particular item off the wiki to fill in the remaining slots?

Cameron: Two bugs about client-side localization are important for HTML 5 and I think there's a misunderstanding about the use of language tags and they are in spec for HTML5, and well, the whole issue of client-side localization is moving forward and it'd be good to discuss that.

paulc: Could we collapse that into that session?

Cameron: Yes.

paulc: Let's add these two bugs to that session.

r12a: We have a few other bugs besides that, and about 15 minutes for the item I want to present at 10. It's getting a little full.

paulc: How many bugs?

r12a: 16 bugs.
... Not sure we'll go through all of those.

darobin: Some may be quick.

paulc: Can someone send a list of those bugs to public-html before that session?

darobin: They're on the wiki.

paulc: The status of these are all bugs in the 130 post LC process?

darobin: Unless I missed it, yes.

paulc: The editor's since July/August have been working on the post-LC bug queue, those that came after the LC date ended. There were 490 of those bugs. Dropped to 460/450 after spam. The editorial team has been attacking that bug list as aggressively as possible.
... Now it's about 130.

<plh> --> https://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=HTML+WG&component=HTML5+spec&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailtype1=substring&email1=&emailtype2=substring&email2=&bug_id_type=anyexact&bug_id

<plh> =&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= 136 bugs

paulc: 136 outstanding bugs. That's a living list.

-> http://w3.org/brief/Mjk1 bug list

paulc: We need more time tomorrow morning. Let's free up half an hour off responsive images and make it 11-12 and 12-12:30 do Cameron's item
... No objections in the room.

ISSUE-195?

<trackbot> ISSUE-195 -- Enhance http request generation from forms -- open

<trackbot> http://www.w3.org/html/wg/tracker/issues/195

paulc: Nomination for last two slots on Friday afternoon?
... We have a bunch of FPWD requests and accessibility items.

plh: what about the bug 18971 Text track should have an id

paulc: That's a media issue.
... One of the media groups, can't remember which --

acolwell: MSE

paulc: MSE were scratching their heads on how IDs work in the video and audio elements. They filed bugs on the main spec.
... And they have more dependent on that bug. Let's have a session of miscellaneous bugs and put the most popular ones in that session.

plh: When?

paulc: Friday afternoon.

acolwell: I don't expect the discussion to take long on track ID, maybe ten minutes.

plh: What about XML stylesheet?

acolwell: Use first of five or ten minutes of MSE session that bug.

paulc: That's a good way to handle it.
... Let's put 14689 and ISSUE-204 in there.
... I want ISSUE-204 to have discussion as we've taken it off the list of formal objections.

darobin: There's also the XML stylesheet thing from XML core. Probably requires 5-10 minutes.

paulc: Ted, ISSUE-204, is 10-15 good?

Ted: Yes.

paulc: Put ten minutes into ISSUE-204 --

plh: Can we do that before preparing for CR?

paulc: All the formal objections have been withdrawn. I just want to ensure they don't reappar.
... Tracker requests, put it under misc bugs.

-> http://intertwingly.net/tmp/wgstatus.html#tracker-requests Tracker Requests

paulc: These are bugs that the filer has disagreed with the disposition. They're all post-LC bugs that have been unresolved.

mjs: There are still 4 tracker requests
... The bugs might align with other topics, such as add an adaptive image element.
... The bug is someone objecting to the extension spec approach. Maybe we should combine that with the responsive images discussion.
... It's bug 18384.

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

-> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18384 Add an adaptive image mechanism

glen: ?? scoped stylesheets??

mjs: I think we're waiting for a bug to specifically identify the bug and hopefully the editor's will resolve it to their satisfaction. The previous bug didn't seem to address CSS-WGs latest concerns about scoped stylesheets.

paulc: mjs and I went to the CSSWG meeting (pre-coffee!!!) and there was some concern about some features in HTML 5 that at CR would be inadequately specced. One was scoped stylesheets and another maybe?

mjs: There was some discussion of pseudo-class elements, but we agreed that wasn't an issue and I believe scoped stylesheets are the only concern. And the scoped stylesheets discussion was still being discussed as being at risk or not.

paulc: If you remove features from your CR you can't go to PR without doing another LCWD. But, if you identify features at risk, don't achieve interop on those features, you can go to PR.
... There is some danger of not getting the features at risk done.
... If we mark it at risk the CSS WG might be okay with that.

plh: I believe so.

mjs: Looking at the other tracker requests, one was a feature request for a better drag and drop model.
... That might be interesting for the next HTML.

paulc: Tobie Langel wants to complain about the current drag and drop model and he asked for time on it. But he didn't update the wiki.
... We added the item to the list. Should we keep 4:30-5 for overflow?
... Can we put 5.1 planning under CR?

plh: Sure.

paulc: Let's do that. darobin and the poor editorial team, we ask for heartbeats and CR drafts and now 5.1 drafts.

darobin: XML Core confirmed to show for stylesheet discussion.

Steve_Faulkner: These last two items: alt guidance is important and maincontent element is just a five minute thing.

paulc: Put those in the last slot, categorize as FPWD request.

SteveF: Are the appropriate people going to be around for the alt-guidance stuff going to be around?

Cynthia: I'll be there late Friday.

paulc: Let's try to get Michael available. Are the editor's going to be leaving before the last slot?
... All editors will be here.
... We might have to overflow into the last session.
... Looks like everyone wants to stay in this room for everything.

ArtB: I just got pinged that I have to go to the AC meeting, can we do the AppCache thing real quick?

Evolving AppCache

<ArtB> http://www.w3.org/2011/web-apps-ws/Papers.html

<darobin> https://etherpad.mozilla.org/appcache

<darobin> https://etherpad.mozilla.org/appcache-london

ArtB: 8 said WebApps WG, 1 said (darobin) HTML and another had strong preference for a community group.
... I sent a mail summarizing what I just said.

<ArtB> WebApps' minutes: http://www.w3.org/2012/10/30-webapps-minutes.html#item06

paulc: For historical purposes: the HTML WG has devolved itself of some responsibilities in the past. mjs or adrianba have a view of what ArtB just said?

<darobin> http://lists.w3.org/Archives/Public/public-html/2012Oct/0194.html -> Art's email

paulc: Anyone in HTML reject Art's request on giving the responsibility of AppCache to WebApps?
... No objections.

darobin: If it moves to WebApps I would like to know if we should pull it from the spec and if WebApps wants to do a delta-spec?

paulc: Delta-spec meaning extension?

darobin: There are multiple options: fix it by monkey-patching it or remove it from HTML5 and let WebApps sort it out.

paulc: Which spec? Marking it at risk in the CR or removing it from the CR?

darobin: Removing it in this case.

mjs: Speaking as an implementer, I'd prefer not to remove it from the spec as it has multiple interoperable impls and has content already. It'd do a disservice for it to remove it.
... Extensions don't have to just be patches or deltas, but can completely replace parts of the spec.
... Dropping it does a disservice to everyone.

adrianba: A few comments: 1. the way that AppCache is embedded in the spec in multiple places and is hard to remove, which is a problem as we missed some of the pieces of AppCache as it was in places we didn't expect. 2. During the discussions that I've seen minutes of with...
... various different people proposing fixing AppCache there's a general consensus that the current implementations of what's in the spec, and that there's content out there, we should make sure to extend or enhance it so that existing content still works. It needs to stay somewhere.

plh: Since we don't have another specification we shouldn't remove it, but mark it at risk I am okay with that.

ArtB: I agree with plh. Leave in, mark at risk. I'll push the WG for someone to start the real work.

James: Inevitably AppCache is an inherent part of the doc loading process and so I don't object to us moving it out, but if we do it in a separate spec we need to coordinate strongly with it to have hooks.

paulc: I didn't hear objection to moving AppCache to WebApps, but did hear objections to removing it from our doc. Also heard people supporting marking it at as a Feature at Risk.
... And if the WebApps WG can move so quickly that it could satisfy us for CR and didn't break existing content perhaps, that by the time we exit CR we could remove it and point as James just said to a spec that would be invoked during the document loading process.
... ArtB when we generate our minutes, I'll do what you did: respond to your email with decision of HTML WG and then it sounds like it's something we need to coordinate at the progress level so we know what progress your group is making.

adrianba: Quick question: ArtB do you believe it is necessary for WebApps to recharter for this work?

ArtB: plh asked that same question. I'd have to look at the charter, but my guess would be yes.

euro: Yes.

paulc: Break time early!
... Who will volunteer to scribe for the next session?

<darobin> "Specifically, because of the close relationship of the WebApps WG and the HTML WG in terms of participants, market, and community, the WebApps WG may opt to take on a limited number of specifications which were initially part of the HTML5 specification that have been split off for more general use with other languages. Consistent with W3C process, an Advisory Committee Review will evaluate whether the additional deliverable should be added to t

<darobin> he WebApps WG charter. The expectation is that if the review is successful, Working Group participants will not be required to re-join the Working Group. For any work transferred to the WebApps WG, the first draft published in the WebApps WG is considered the first public Working Draft for application of the Patent Policy exclusion rules."

paulc: Kris volunteers to scribe. Break now.

<krisk> I can scribe the next session

Responsive Images

<krisk> scribe: krisk

We are about to get started on the responsive images

<mjs> http://usecases.responsiveimages.org

<pal> pbakaus has joined #html-wg

mjs: see the pasted in link above

<mjs> http://picture.responsiveimages.org

<mjs> http://dev.w3.org/html5/srcset/

mjs: two drafts for the use cases
... their could be some convergence for these use cases
... would anyone like to chat about these?

<darobin> dadarobin has joined #html-wg

marcos: I can walk room through the use cases

<Marcos> responsiveimagescg.github.com/meta/presentations/TPAC2012

group looking at the deck from marcos

marcos: background had a hard time dealing with high res devices
... got more organized and started a CG

CG == community group

marcos: from the feedback we started to create use cases
... we have also started to think about a new element, but this is not the primary use case
... 'ART DIRECTION' is the primary use case
... 'DESIGN BREAKPOINTS' is the secondary use case

see the slides

targets getting the right image for the right size and can potentially save bandwidth

marcos: printing has much, much larger DPI (1000 vs 96), images and text is a problem

Now on the media types and featuress

scribe: slide

marcos: another use case is orientation
... for a device
... another use case is relative units
... zooming in on a page or section of the page, can result in a bad image next 2 clear text
... need apis to switch media sources on the fly (e.g. canvas, webrtc)

<scribe> ... new image formats are coming...

UNKNOWN_SPEAKER: jpeg2000, Web_, JPEG-XR
... very hard for web devs to do this w/o hacks (like ua sniffing)
... mobile platform would benifit alot since the new formats can have a significant bandwidth saving (30%)
... 'match image sources with media queries - upate the source of an image automatically'
... 'no server-side processing'
... 'automatic fallback to legacy useragents'
... 'simple api'

'what is the current source'

'what media is attached'

scribe: now on the breakpoint friendly slie (7)
... finally the requirement needs ot be poly-fillable

shelly: have we though about high contrast use cases

<cyns> http://msdn.microsoft.com/en-us/library/windows/apps/hh465764.aspx

marcos: we thought about, but looked at stuff that is online today

cyns: the above link is how w instruct people to address high contrast

<cyns> http://msdn.microsoft.com/en-us/library/windows/apps/hh465764.aspx

marcos: we need to provide a who and where to make it a use case

cyns: I'll send you some who and where for your use cases

marcos: here is our solution!
... may or may notpaulc:

<hsivonen> need to compare that design with epub night reading mode design

marcos: the picture element
... see the picture element slide
... it looks alot like the html5 video element, multiple sources and fallback

<hsivonen> so get rid of prefixes!

marcos: though vendor prefixing gets really messy
... we also have fallback text for accessibility
... showing a live demo of this in action

???: private chromium build with a private patch

marcos: showing source of the page

<hober> s/???/Yoav/

<hsivonen> yoav weiss

yoav: you can see as the browser is resized the network trace shows getting the right image automatically
... see how image is prefetched before css in network trace
... we may need to reconsider how the fallback image gets downloaded...which is not needed and bad for perf

marcos: it does have some trade-offs, it does work...maybe not ideal but does solve some real issues
... moving on to the srcset attribute

see ROUND-1 fight slide comparing srcset vs picture element

marocs: srcset would need an api to complete the use case

<Stevef> paulc: re timing of alt and main element discussions, apogies I relaized after that my flight was earlier than i thought, so need to leave TPAC at 4, requesting that the disucssion be moved to an ealrier time slot

marcos: it's not trivial to do the parsing - it would be better to have a DOMTokenList (which is how classlist works)
... so one path would be to combine srcset and picture element

marocs: result is less code

marcos: can we have a mailing list?

the html mailing list is too much

marcos: questions?

pal: have you looked at CSS for solutions?

<pal> pal?

marcos: using css it's possible, but you can't use the image element must use divs

yoav: css doesn't change alot, unlike image/content

mjs: is it possible for someone to talk about srcset?
... it seems odd that the 'round 1 -flight' only have red checks for srcset

hober: will talk about srcset

<hsivonen> s/fligth/fight/

hober: we are not designing a feature in isolation
... for example, css, svg, etc...
... two use cases...
... one is clipping and image
... the motivation is to get the right image loaded taking into account for size and bandwidth
... part of the design for srcset, the ua can pick the right asset
... that can save bandwidth
... multiple elements is complex and though we do this for audio/video
... they didn't exist. Unlike the image element
... if consider picking an image on pixel density, it's quite appealing to use srcset

looking at round 1 flight slide

marcos: do people like the current syntax for srcset? how do we deal with this conflict
... some people are quite concerned with ems -> 1, 2, 3 times

marocs: not bad, maybe just a educational problem..since it's a bit differenet?

marcos: can we work together to make this better?

hober: of course
... a change to the syntax could be made and I'm happy to listen to suggestions

marcos: is it possble to makes an image load in srcset? for example for a web author needs to be force the image being loaded to test

hober: you could just remove the srcset and then test

yoav: one comment on vw/vh
... zoom designs doesn't impact the view port pixles

hsivonen: if you zoom in on a desktop browser, indeed pixel change
... you only need ems when the UA has the base font size not equal to 16
... 1 em == 16px
... part of the design of srcset is because site compat depends upon 1 em == 16px

mjs: I don't thing you'll find a browser that doesn't change one vs the other (em, pixle)
... so the user stylesheet is the only case

<hober> ack

cyns you are on the q

ack

<SimonPieters> "new" technique that seems to solve the "retina" use case with just one image that has smaller file size than a "normal" image: http://blog.netvlies.nl/design-interactie/retina-revolution/

simonpieters: see link
... when you zoom in base vs retina would solve some of the use cases

hsivonen: three comments on the original presentation
... wondering about the grey scale graph, color sentitive photos vs charts?
... we already have svg and media queries which is a better way to do this already
... another point is new image formats, adding new image formats should not be take lightly
... the addition to the ecosystem is very costly and has a long, long life and attack surface
... maybe I am wrong...but I recall a site like facebook had lots of jpgs that were not compresed to the max

<adrianba> s/..maybe/... maybe/

hsivonen: given the size of the site and number of jpgs on their site. It might be better to push on the jpg decoder rather than switch to a new format

<adrianba> s/..we/... we/

<adrianba> s/..another/... another/

<adrianba> s/..the addition/... the addition/

hsivonen: we may find arithmatic jpg encoding could be used as well

<adrianba> s/..given/... given/

<jgraham> I just ran the experiment on arithmetic encoding, and it seems that browsers don't support it

marcos: first comment on svg, not very many tools or used to create svg

mjs: adobe supports this...

marcos: not widely available and costs alot, even inkscape though free is not great

mjs: we need to get back to the q

marcos: we have smaller cdn's that would use this so facebook may not be the best example

cabnier: their is no reason why the img tag could not have other attributes
... what happens on older browsers, with the image and p tags?

cyril: he we are talking about content switching and we should have a way to combine content and css

cyri: file size seems like a good pivot

s/cyri/cyril/

cyril: seems like this should work with video, for example streaming video
... in svg we are looking at a simalar issue
... how do we do make sure we do less http requests, though this doesn't seem to address

mjs: The early example was intresting, but what about pngs that are used for UI?
... since my experience alot of UI is not jpgs and is pngs

<SimonPieters> http://simon.html5.org/dump/compressive/size-50-quality-40-subsampling-422.JPG (214K) vs http://simon.html5.org/dump/compressive/size-50-quality-40-subsampling-420.JPG (198K)

simonpieters: seems like we need more research for logos and I agree with hsivonen on push the jpg encoder

see the jpgs samples above

paulc: I want to switch away from the technical discussion and talk about how to move these proposals forward
... though we didn't make a session for lists discussion and we should revisit since new items have a requirement for new lists
... how are we going to move these forward?
... do we just need to find a location and then move on...

<Marcos> +q

hsivonen: comment on svg
... the usage share for browsers that support is at 81% vs 0% for addaptive images
... we should just svg since it's useable and not add a new item format
... if their are bugs (snap to pixels) then we should get the bugs fixed (perf, etc..)
... for tools most logos come from vector based editiors
... we should be pushing for svg rather than add a new format

marcos: we are not throwing svg under the bus, we love svg

yoav: comment on jpg decoder...
..yoav: people are actively working on jpg encoder and I don't think browsers support aritmatic encoders

hsivonen: you are correct

yoav: no alpha channel exists and thus pngs are used

hsivonen: that is not good reason

yoav: we may want to give future image format a chance

hober: the comment on choosing an asset is works well using css+media query via clipping
... and you don't end up with another http request
... so you don't need either

mjs: I encourage people to continue this discussion on the list and paul and myself will look to get the list issue resolved

Issue 195: Enhance HTTP request generation from forms

next discusson: Isssue 195

s/Isssue/Issue/

<hsivonen> DELETE requested across the Web? really?

cabanier: the changes involved is to add more HTTP enhancements beyond GET/POST
... we are proposing to say you can't use ADD or DELETE
... it's a black list
... add a new element to the form, payload

<MikeSmith> s/cabanier/cjones/

cabanier: payload would have three new control terms

could bind to query string, http request header and body (like post)

<MikeSmith> s/member:cabanier: the changes /cjones; the changes/

scribe: it also enables a form to manipulate the query string, body and header.

<MikeSmith> s/cabanier: the changes /cjones; the changes/

scribe: this doesn't impact xforms
... this is just an addition

<MikeSmith> s/cabanier: we are proposing/cjones: we are proposing/

scribe: we are also wanting to add two new form control fields

<paulc> Change proposal pro ISSUE-195: http://www.w3.org/wiki/User:Cjones/ISSUE-195

<MikeSmith> s/cabanier: it's a black list/cjones: it's a black list/

The three are

<paulc> Counter proposal from Ted: http://www.w3.org/html/wg/wiki/User:Eoconnor/ISSUE-195

scribe: username/password
... used for auth and can work with http auth directly (just like XHR)
... just want to provide this in static html
... another is a 'logout' attribute, since we adding auth we should add this as well
... expects server to do the work
... we have a proposal that we have been working on and will be looking to create an extension spec and get this integrated into the lifecycle of HTML5
... we'll have an extension spec by the end of the year

paulc: hober counter proposal to ISSUE 195 was that this was too late
... this is a good test for extension spec

hober: I think the extension spec could be used
... I recall gecko had support of this and it was pulled, can someone comment on this?

<MikeSmith> s/cabanier: the changes involved/cjones: the changes involved/

simonpieters: the proposal enables new things that go over the wire, has security implication be reviewed?
... in legacy applications

cabanier: this is all available today in XHR so their should be no additional security issues

simonpieters: I disagree, many sites apply blacklist approaches

<Stevef> zakim [IPcaller] is me

sicking: commenting about gecko..
... I was not involved specifically, though we are trying to get away of password
... since passwords have problems and want to have a ID
... we would like to move to crypto tokens and not investing in user/passwords, since crypto is better

<Zakim> mjs, you wanted to talk about security

mjs: XHR has been on same origin until CORS
... it's not simple as saying XHR is safe:

<Marcos> +q

cabanier: this stuff was added for UAs that has not CORS support, etc..
... it just about basic html

<Marcos> -q
..cabanier: going back to the gecko bug, it initially didn't have some headers which made PUSH DELETE verbs useless

cjones: redirects were not being handled which also impacted XHR

hsivonen: during the intro was that this was requested alot on the web, which I don't believe is true.
... do we have any data that indicates this is really a key need for this feature
... what is the actualy implementation environement since XHR is available all over
... seems odd to favor a user agent or environment that doesn't have XHR

cjones: the web should be able to work without javascript support
... the intrest comes from about every 6 months on public html
... stackoverflow or other programing sites this comes up alot...
... php supports this and may other backend solutions as well
... once they don't find this they stop looking...

hsivonen: why did people stop and not use XHR?

cjones: SGML-based template solutions are what people are using

jgraham: it may not really implementable by a browser, from what I heard today browsers vendors would not be happy about implementing.

<yoav_> hsivonen - This is the "em based MQ" technique I was referring to in the responsive images session http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html

sorry cjones/cabanier about the mixup

This session is over, we'll start again in 1:12 minutes

<yoav_> http://blog.cloudfour.com/the-ems-have-it-proportional-media-queries-ftw/

<craig> ping

<matt> Chair: Paul_Cotton

<matt> Meeting: HTML WG TPAC F2F Day 1

<glenn> scribenick: glenn

paulc: 2-3:30pm session: MSE, HTML5 Bug 18971
... coffee break 3-4pm
... 2nd session 4-5:30pm perhaps longer
... have room til 1800
... MSE - media source extensions
... and ED, not yet FPWD
... under development of media TF since May F2F
... tuesday morning telcons alternate between MSE/EME

<matt> MSE Bugs

<paulc> http://lists.w3.org/Archives/Public/public-html-media/2012Oct/0051.html

paulc: see link above
... this format will drive discussion
... bugs are rows in this table with status
... needsinfo means don't understand
... wontfix ... eds believe no problem, or reporter doesn't understand spec
... 2nd list of bugs categorized as new feature
... 11 new features
... may run out of time
... acolwell, how would you like to proceed?

acolwell: 17002

<matt> Bug 17002 - Specify a mechanism to determine which SourceBuffer an AudioTrack,VideoTrack, or TextTrack belong to.

<MikeSmith> infobot inform plh radio check

<matt> MSE Bug summary

<matt> s/infobot inform plh radio check//

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

acolwell: bug 17002 - desire to take track on elt and figure which source buffers assoc witih it
... proposal to use ID on track
... looking at existing track intfcs, found text track doesn't have ID
... i.e., needs @id on track element
... are folks OK with adding to make consistent with A/V tracks?

paulc: reads bug description
... any q/c? on this proposal?

<matt> Bug 18971 - TextTrack should have an id attribute

plh: asks how one gets track?
... see 4.8.9 defines HTMLTrackElement

<matt> Track Element

<plh> http://www.w3.org/TR/html5/the-track-element.html#the-track-element

<matt> video element

http://dev.w3.org/html5/spec/single-page.html#texttrack

travis: HTMLTrackElement has ID, but TrackElement does not

<tantek> so this is the trackid

plh: tnx

<SimonPieters> s/but TrackElement/but TextTrack/

travis: some concerns in WebRTC to maintain consistency

<dsinger> seems like it shouldn't make a difference to script whether I supply a multiplex including the text track (e.g. an MP4 file) or a separate <track> element containing it. In multiplexes all tracks have IDs, in the latter case we need them to also.

glenn: asks if name to use would be 'id' same as name of property on HTMLTextElement

acolwell: yes

glenn: probably confusing for authors

dsinger: ... [scribe missed]

paulc: MSE eds should work with HTML5 eds to get this into HTML5
... will have some issues with layering back into 5.0
... travis will propose solution to 17002
... hope to publish 5.1 WD as soon as possible

robin: est ~2wks

acolwell: should 5.1 spec be refd in general from MSE?

paulc: suggests it is possible to define @id in MSE itself

<darobin> s/est ~2wks/est ~2wks before the CfC/

simonpieters: objects to having MSE define, but prefers defining in 5.1 itself

paulc: this would delay moving MSE forward to 2016 if it has norm ref to 5.1

simonpieters: notes that this isn't necessarily a barrier

paulc: depends on how stable refd spec is

ACTION to paulc Figure out how Extension specs can refer to 5.1

<trackbot> Sorry, couldn't find to. You can review and register nicknames at <http://www.w3.org/html/wg/tracker/users>.

<scribe> ACTION: paulc to Figure out how extension specs can refer to HTML 5.1 [recorded in http://www.w3.org/2012/11/01-html-wg-minutes.html#action01]

<trackbot> Created ACTION-223 - Figure out how extension specs can refer to HTML 5.1 [on Paul Cotton - due 2012-11-08].

acolwell: 18960

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

<matt> Bug 18960 - Define how AudioTrack.id & VideoTrack.id are generated

acolwell: when using media source, about what fields should return

s/fields/id fields/

scribe: need to be clearer about which ids are used

cyril: can't just copy id from container file
... e.g., a and v tracks may use same id

acolwell: if using a manifest using info about ids, can make use of that info
... can discuss

paulc: asks if this is to give a name to id?

acolwell: MSE can permit construction where tracks change over times
... therefore more collision potential
... need to create rule to maintain track id uniqueness

simonpieters: are we still discussing text track id?

acolwell: also audio and video

simonpieters: why uniqueness constraint?

acolwell: due to getTrackById()
... if not unique, can't return one object
... didn't want to cause change in HTML spec

simonpieters: if we discover problem, then should consider changing HTML spec

<matt> [[PLEASE don't change the semantics of ID]]

<Zakim> dsinger, you wanted to agree that the IDs need to be unique within the media element, and consistent over time

dsinger: if playing a media file directly, then ids come from media
... if coming from dash, then dash layer should provide ids
... we should write rule for (a) unique, (b) consistent over time

markw: this is example of a general category
... can write code that doesn't need to know much about source
... but MSE needs more
... concurs with dsinger about defining consistency rules

paulc: summarizes - multiple options presented here for consideration

acolwell: one other thing ... if we don't have original id, then in a multiplex, can't identify particular track

adrianba: depends on how one views MSE and common uses
... if you look at MSE, API is designed to use formats that use manifest

<Cyril> s/MSE, API is/MSE as an API/

adrianba: if you look at MSE as way of abstracting how data gets into media element, then may not have a manifest
... should consider how to approach MSE in this latter case, since no manifest available

cyril: q is should id be static?
... may need to change id

acolwell: thinks spec currently says it shouldn't change
... need to choose which rule to violate

markw: problematic if UA generates ids

<SimonPieters> We could have two attributes: id (stable, unique) and containerid (from the container, not necessarily unique or stable)

markw: if script supplies ids, then should allow control by script

<SimonPieters> If there are use cases for having both

paulc: who owns this bug?

<dsinger> I had two cases, not one. If the media engine is playing a manifest directly, then the manifest is the 'origin' of IDs. If the media source extensions are supplying media, they are the source of IDs. (I don't care what is driving those scripts, in the latter case). We just need to say that those IDs are unique within the media element and consistent over time, and leave it to the 'surface' of the media to ensure that's true.

paulc: eds need to assign bug owner

acolwell: bug 18601

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

acolwell: should not require initialization segment?
... pat/pmt in TS proposal is considered initialization segment

s/pat\/pmt/PAT\/PMT/

dsinger: notes that some formats are self-initializing

acolwell: some slight differences in terminology about what 'initialization segment' means

paulc: proposal is WONTFIX unless someone brings a media format

<matt> s|pat/pmt|PAT/PMT|

<hober> s|pat/pmt|PAT/PMT|

acolwell: remove conflict

paulc: 19531

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

<dsinger> notes that the definition of initialization segment to me, at least, excludes self-initializing media segments, and if that's not intended the text (and examples) need revision

adrianba: issue about what mime types MSE could accept
... need feedback on two proposals
... one is add method isTypeSupported()
... will say if source buffer can be created for some mime type
... alternate is something like canPlayType() => probably, maybe, no
... isn't clear which is best

s/adrianba:/acolwell:/

scribe: prefers former (return binary value)

adrianba: matter of consistency

<markw> bool isTypeSupported seems ok to me, but if canPlayType is NO then isTypeSupported should be false

adrianba: if you have code for canPlayType for basic media, then perhaps should reuse that here
... in EME, will extend canPlayType()
... may be necessary to apply same params here (with MSE)

<Zakim> Cyril, you wanted to say canPlayType is for when you don't have codec parameters

cyril: canPlayType() .... may not know how many tracks
... but in this case could be asked on a per-track basis

<markw> isContainerSupported ?

acolwell: this seems more about whether byte stream format is supported as opposed to whether that content can be played
... donesn't think anything gained by using canPlayType... thinks returning "probably" is not helpful
... either you support that format or you don't

<Zakim> dsinger, you wanted to say that we need a differentiation between whole files and MSE-supported files

cyril: may not care about track format vs container format

dsinger: asking different questions
... may support may types but not support playing with MSE
... thinks orthogonal issues of getting segments into media versus playing media (consisting of such segments)

markw: agrees, wonders if 'isContainerSupported' is better

paulc: acolwell, do you have enough here for a decision?

acolwell: agrees testing 2 diff things

<markw> is it possible that an implementation could support some codec X when supplied in an WebM file but not when supplied in WebM format over MediaSource ? We hope not.

<Cyril> To answer Dave's comment, there could be the case that someone supports H264 in MP4 but not H264 in MPEG-2 TS (or vice versa)

acolwell: interpreted dsinger as supporting position

adrianba: does anyone object to isTypeSupported on MS?

paulc: no objections noted

cyril: testing only container

<adrianba> s/on MS?/on MSE?/

acolwell: bug 18962

<matt> Bug 18962 - Allow appending with XHR

acolwell: use XHT to append data?

s/XHT/XHR/

acolwell: would allow appending stream object that comes from XHR

<SimonPieters> http://xhr.spec.whatwg.org/ (search for "stream")

adrianba: raised in WebApps, has action to write spec
... addition of some events to signal progress of append
... purpose - asynchronously append data from network stream without having to involve JS
... should reduce code complexity, better performance (memory and speed)
... while XHR is primary use case, but doesn't actually need to know source is XHR
... needs way to tell application when its safe to append again
... need to understand what circumstances can have append fail
... should assume appends [always] succeed? probably not
... may need to indicate what type of failure occurred

paulc: this bug refers to that XHR addition?

adrianba: yes

cyril: is there a requirement array is populated in JS?
... could it be populated only when accessed [in JS]?

acolwell: it's possible, but not how [Google] currently implements it

adrianba: during download possible to look at array buffer
... expected array buffer represents continguous memory block
... wants to allow media engine to be in control of moving data into [decoder]

markw: thinks couldn't get array buffer [with known length] until transfer complete

acolwell: thinks he has enough to run with this

<markw> also, can't use arraybuffer with open range requests

<matt> Bug 18963 - Provide a mechanism for rate limiting appending

paulc: bug 18963

adrianba: should there be mechanism to inform app it is appending data faster than being consumed?
... i.e., rate limiting
... do we really need to do this now?
... or is this just an enhancement [that can be postponed]
... what is current behavior for append if buffer is full?

acolwell: currently append won't fail
... spec can do GC
... e.g., to remove parts of source buffer
... chrome will trim material earlier than current playback position
... tries to assess usefulness of data for throwing away
... if there were event, could use remove[Data] to have app make decisions

adrianba: failing append used for rate limiting

cyril: would be nice to have a presentation occupancy indicator

markw: not clear there's a fixed amount of memory for source buffer

<Cyril> s/a presentation occupancy/a buffer occupancy/

markw: if error on append, then wait and try again

acolwell: if there isn't threshold, then throw an error instead of GC

cyril: thinks resolution is to throw exception, but may want to know finer exception reason

acolwell: agreed
... bug 18709 - remove [data] method

s/data/time ranges/

<matt> Bug 18709 - Add SourceBuffer.remove() method

scribe: what if remove on current playback position?
... if data gets appended over playback position, then what?
... stay paused? seek?
... keyframe?
... if seeked, then should those events be internal only or surfaced [to script]?

markw: general rule is if you don't have data for current playback position
... then like being in network stall
... when data starts arriving, like resuming from stall
... odd situation
... if resumed data doesn't really match, then error case
... can't happen in current format

acolwell: artifact of MSE

markw: like appending with data not starting with I-frame
... do you throw away up to I-frame?

dsinger: isn't this dependent on implementation behavior?
... most decoders just keep playing (skipping as needed)
... i.e., this is a quality of implementation issue

paulc: could add "this is undedefined" to spec

acolwell: hearing "stall" but not "seek"

<markw> playback starts again automatically, as if resuming from a network stall, but what is displayed before getting to the next I-Frame is undefined

paulc: bug 17094
... are there MPEG-2 TS experts here?

<matt> Bug 17094 - Define segment formats for MPEG2-TS

<scribe> ACTION: glenn to Follow up with Bob Lund on bug 17094 [recorded in http://www.w3.org/2012/11/01-html-wg-minutes.html#action02]

<trackbot> Sorry, couldn't find glenn. You can review and register nicknames at <http://www.w3.org/html/wg/tracker/users>.

<dsinger> self-initing MP4 files all start at time 0, as well, so their order is indeterminate. the same question arises

acolwell: because there are no markers for begin/end in media source, there is some issue

dsinger: same (similar?) issue with MPEG-4

acolwell: no begin/end in media segment

<Cyril> to answer dave's question, for MP4 you'd have to use timestampOffset when appending

<markw> with dash/mp4 you don't have a sequence of self-initializing media segments. You just have one and you extract the sub-segments.

<acolwell> acolwell: Because there are no markers for the begin/end of a media segment, it is difficult for MSE to differentiate a TS discontinuity from a out-of-order append.

<dsinger> so, for any format, use timestampoffset to set the correct overall timeline (i.e. after applying this, the timestamps are in the global order)

<markw> the timestamps within a period are monotonic, unlike mpeg2 ts

<matt> Bug 17002 - Specify a mechanism to determine which SourceBuffer an AudioTrack,VideoTrack, or TextTrack belong to.

paulc: bug 17002

adrianba: mechanism for mapping track object against html media element back to source buffer
... related to track ids discussion
... given a media element, identify active track, and determine which source buffer applies so you know where to append
... adrianba prefers using id string if it can be made to work
... if have track id, then should be able to map back to source buffer

acolwell: use object instead of id?
... yes, that would remove dependency on 5.1

adrianba: any ojection?

[scribe: none heard]

<adrianba> i/acolwell: use/adrianba: perhaps we should now use the objects to remove the dependency on ids - i'd like to ask if anybody objects to that/

<Travis> Alternate form using union types from WebIDL= SourceBuffer? getSourceBuffer((VideoTrack or AudioTrack or TextTrack) track);

<Travis> Overloaded functions is also supported as-is.

<matt> Draft charter

paulc: presents charter draft
... deliverables: (1) HtML5 et al (2) HTML 5.1
... dates from "Plan 2014"
... believes plh is OK if he sends to draft to charter with NO SCHEDULE for media extensions
... may get comments: why no schedule for media extensions?

<hbang> rssagent, make minutes

paulc: but we could choose 5.1 schedule for media extensions
... in which case, would have FPWD before end of 2012, but no REC until Q42016
... seems slow
... in media TF have discussed
... haven't brought to FPWD due to rennovation of APIs, more object oriented, etc.
... these bugs are primarily clean up from tha twork

s/tha twork/that work/

scribe: there is a disclosure requirement after FPWD
... not only should design but also scope be well understood before FPWD due to IPR policy consequences
... media TF would like to go to FPWD before end of 2012 [no matter what]
... believes vast majority of bugs will be addressed by then
... if 5.1 sched isn't used, then can make up a [faster] sched
... paulc would propose as follows:
... FPWD - Q412
... how long to LC?

markw: what are LC exit criteria?

paulc: an extension could be either more strict or more lax than 5.0
... should evaluate "public permissive" but may choose differently
... indeed individual media extensions could have distinct criteria
... can LC be complete in 2013
... suggest Q413 for LC completion

<jgraham> I note that CR typically does have test requirements

<Zakim> adrianba, you wanted to talk about milestones

adrianba: proposes to move aggressively to LC
... shouldn't delay

paulc: will need to meet exit criteria... e.g., impls and some testing

adrianba: proposes Q213 for LC completion

<Zakim> ArtB, you wanted to discuss schedule

artb: recommends being as vague and as non-committal as possible in charter

markw: supports agressive time scale, no opinion on whether its in charter
... has some confident can meet an aggressive time scale

mark_vickers: concurs... be aggressive

adrianba: supports being vague in published dates, but aggressive on work

mjs: for HTML5, have milestones in charter

<adrianba> s/published dates/CR and PR dates/

mjs: due to extreme interest in schedule

<adrianba> s/aggressive on work/agressive on LC/

mjs: but nobody has pressed for schedule on other deliverables
... little advantage to public date commitments

<adrianba> +1 to mjs

acolwell: agrees with mjs

<matt> [[I've seen schedules at times bring people into the process sooner rather than later, but don't care if it's in the charter or not]]

paulc: is there any objection to not including date sched for media extensions in charter?
... none heard... we'll go with that as current position

end of this session

<Travis> scribeNick: Travis

EME

<BobLund> I've got to leave at half past the hour.

<paulc> http://lists.w3.org/Archives/Public/public-html-media/2012Nov/0006.html

<matt> EME bugs

paulc: looking into the priorized list of EME bugs
... look at the attachment in Paul's mail link

<Masahito> +q

masinter:

<matt> s/masinter://

Masahito: some comments on EME (co-chair of WebTV XG)
... storage proposal for media content (caching)--how will EME be related to protect that content?

<matt> TV APIs discussion yesterday

<adrianba> i/scribenick: glenn/Topic: Media Source Extension/

<matt> Web and TV IG minutes

Masahito: Use cases for EME seem to address our cases so far.
... Can I add some additional uses cases in the draft?

<tomoyuki> s/WebTV XG/Web and TV IG/

Masahito: Don't seem many use cases in the current draft.

paulc: has anyone filed bugs for other use cases?

ddorwin1: goal is that it's not restrive. That's why there's not many use cases.
... we know we need to add an introduction to how to use.
... not sure where that would go.

paulc: typical W3C will write a non-normative primer.
... contains examples of what the technology might solve.
... example was XMLSchema.
... doesn't need to go in the spec itself.
... the audience for the specs are very different.

<Zakim> adrianba, you wanted to comment on the Web and TV IG use cases

adrianba: remember that this work is a follow-up the requirements gathered by web and TV IG.
... there are a bunch of use cases and reqs that the IG gathered.
... I repeat that as the Web and TV IG reviewes charter and scope, that they should identify use cases and reqs for content in general...
... and which are satisified by EME and other systems and what the gaps are.

Masahito: Agree, that's a good direction.
... also thinking that from EME's POV, it already covers everything we know
... I'm suggesting that we specifically describe how EME will be used in such cases.

markv: Original proposal was done in the IG's task force.

paulc: It would be very useful to figure out how to bridge the gulf between the tech spec and the use cases.
... moving on..

<ddorwin1> updated figure: http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#introduction

ddorwin1: compaint that it wasn't clear what happens to the decrypted frame.
... updated it this week.
... clarified in the graphic in the spec.
... the frames (where they go) is up to the CDM.

paulc: graphic is more up-to-date than the prose?

ddorwin1: yes.

paulc: There is work to do to make the prose match the diagram.

ddorwin1: overview doc was [tried to be] passed off to the IG

<markw> proposed text to clarify frame handling is here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16544

ddorwin1: For EME: we could put a static key type api.
... For this group, do we leave canPlayType?

cyril: will the encryption system be different depending on the media type?

ddorwin1: Encryption techinque depends on the container.
... real question: can this key system support ISO common encryption.
... does this UA have a key system X, and does this UA support that?
... it's a matter of where it is in the API

markw: A UA might support codec A and keysystem B, but not not support the combination.

ddorwin1: It's a matter of where you want to ask the question.

markw: If you ask the full combination than that's fine.

adrianba: Wondering what's the compatibility of the container format with the key system.
... canPlayType on the media element will give us the vague response.
... if we move it to MSE, then it might be the same good answer for EME.

paulc: Onto item 4.

<matt> Bug 17673 - Define Initialization Data for implementations that choose to support the ISO Base Media File Format

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

ddorwin1: currently working on two containers, see two bugs on how to use those.
... question on how to handle ISO

johnsimmons: structure of container guidelines for webM and ISO are the same
... what's the screen info, initializtion and events, etc.
... structure is the same
... we decided to emphaises the common encryption detection scheme
... replicates some of the info from the ISO 23001-7 spec
... expected to look up the details in the spec.
... most discussion has been on the initialization steps where most of the discussion has taken place.
... [see bottom of the bug]

<ddorwin1> initData is a concatenated list of PSSH blocks

<matt> Technical info from John

johnsimmons: central issue is that this follows the commen ency spec. except the part about concatenating the pssh blocks

<adrianba> s/commen/common/

paulc: proposal is to put this into the spec.

<Zakim> dsinger, you wanted to say that we should say how to identify encryption in general

dsinger: It's a little too specific.
... think we should have more generic text for other encryption seq.
... don't mind documenting how to handle common ecryp.

johnsimmons: I don't object, if someone provides common language.

<Cyril> such documentation should be in the ISO spec not in the EME spec

paulc: dsinger and john will talk offline to come up with common text.

<dsinger> would prefer that the section was a little more layered, detecting encryption in general and how to handle it, and then encryption-system specific considerations

markw: when looking at track/sample depends on the box, but it also depends on looking at the flag.

cyrill: is really the job's group to document MP4 format?

markw: you have to translate to ISO format to the language in this spec.
... you could say it's informative, otherwise someone might concluded that if the sample group is encrypted than the whole thing is encrypted.

cyril: we should make sure we identify what's normative versus what isn't.

<adrianba> Informative container information

<markw> my point was that as well as the track level default (Track Encryption Box) and sample group level default there is also a per sample flag indicating whether a sample is encrypted

adrianba: I think the spec's clear about how the mapping happens.
... if you choose to support a format, then you should do it per spec so that it is interoperable.
... there's a css bug that makes it look wrong

paulc: johnsimmons proposed text is to be non-normative

markw: I think the termonology mapping should be normative. An encryped block in the text means a sample.

paulc: the part you want to be normative is the mapping right?

adrianba: I want to think about that. We're trying to make the text solve that, but without normative reqs for a particular format.
... we want to say "it's a must to do it this way, if you do it this way"
... I have some concerns, as I said. We'll continue that discussion, just not today.

<matt> Bug 17682 - Clear Key: Document how keys and key IDs are associated

<adrianba> we need to fix the spec to ensure the "non-normative" appears correctly across browsers

ddorwin1: In the original spec, addKey() had two params... it worked well for webM, but doesn't scale for having multipel keys at a time.
... for clearkey, was a problem

johnsimmons: wanted clearkey to be handled by a CDM
... [explains clearkey vs drm systems]
... The inconsistency is: it was unclear when all that was being passed was a key.
... clearkey needed some kind of initData with keyid key pair.
... I proposed using RFC 6030, another propsal using JSON was also suggested.
... my text in the bug is to ref one or the other of the container specs.

<matt> MarkW's proposal using JSON

<matt> s/JSON/JSON Web Key/

johnsimmons: and to change the text for clearkey CDN that you would use these containers.
... we also want examples for ISO and webM cases with a presumed same container.

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

Markw: JSON webkey doesn't yet support this.
... it would be trivial for it to support symetric keys, but it doesn't yet.

johnsimmons: I prefer a JSON solution.

paulc: propose that the editors add the proposal from mark

markw: put a referenece in the appendix and get something into an IANA registery.

paulc: ... and when it's ready, you can put the link to the registry.
... John's outline, with mark's solution is the path forward

markv: also prefer that solution, but there's a dependency that could hurt our agressive schedule.

paulc: for mimetypes to they get pulled out of the appendix section of the spec up till CR...
... then from CR->PR and upon registry, then it can come out (very late)

<matt> Bug 17470 - Provide specific guidance on when generateKeyRequest should be called

paulc: looking at bug 17470

<matt> Bug 17660 - need token relative with user identity for a new generateKeyRequest parameter

ddorwin: next bug is 17660
... provides an optional param for user identify
... the app should handle the identification.
... got a request to reopen.
... to use the keyrequest as a trusted transport stream.
... that's not what it was intended to be used for.

paulc: Sees that Joe's not here. We shouldn't make a decision without his input.

ddorwin: would like to have a discussion?
... init data doesn't provide any other means of putting licence data into the request.
... there's no other way to provide a secure channel as it's coming from JS directly anyway.
... Joe came up with an alternative way to do this.

<matt> mail on 17660 from Joe Steele

markw: in the threads there are two proposals.
... the first ask was ambiguous, they both come down to having an add'n param for createSession.
... one reason is to piggyback app messages to the server.
... the other proposal is for keysystem dependend.
... the app would need to know about the keysystem
... I don't think we need either one.
... good to hear from anyone else?

adrianba: I'm not the person looking to support those. On the contrary, in the case of providing data to be packaged to the server--we definately do not want to support that.
... on the second point, providing addn'l data, we agree with markw that it shouldn't be necessary and our implementation wouldn't use it if it was there.

paulc: Again, since Martin/Joe is not here, we should reply back to the bug noting the conversation here at TPAC.

martin: I still believe it's useful to have that data sent.

paulc: classic question for v1 spec -- is it necessary?
... we'll need to find consensus

<adrianba> martin said that he thinks it is useful because it avoids requiring the network transport to be a secure channel

<markw> you can avoid using a secure transport channel by using a secure application protocol, for which you could consider using the WebCrpyto APIs

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

<matt> Bug 17203 - Should session ID be required?

adrianba: session id was added to correlate key message events to add key responses (before refactoring of the API)
... with the changes to the spec, new question: what is the session id for?
... and should it be always required?
... we probably want to tie this to markw key release question.
... we're wondering if this is optional or manditory?
... the reason this has been kept alive, it's not a big overhead to have an incrementing int.
... if everyone implements it this way, is that really all that useful?

ddorwin: if we have it, it should be mandatory. Can't say how useful it is without key release.

adrianba: question for markw
... I recall you describing use cases for a session id related to key message, so that you could capture telemetry about the session from the app's logic
... could you elaborate?

markw: Not sure if can elaborage, but that use case is now covered by the OO API. I now get an object, so I can hang stuff off the object.
... (for as long as that object is alive)
... we'd still like to have it because you may come back hours or days later to recover the object, and you'd need something to refer to it.

paulc: Is that enough motiviation to have session id?

ddorwin: there may not be use cases unless they were doing keyrelease...

<markw> s/elaborage/elaborate/

ddorwin: another option to explore (testing the waters...) if the session id read/write it for various reasons... they don't need it from the key system.

paulc: Makes me wonder if this is then mandatory for v1.

adrianba: we should propose that this issue be part of the secure key release discussion.

<matt> Bug 18531 - Consider renaming addKey method

ddorwin: originaly you use addkey to provide a licence. There's other cases for adding keys/changing keys, etc.
... proposals to change the name since it's not always a key.
... we settled on "update" no one liked it, but it was the best we had.
... any objections?

paulc: any comments?

[ no comments]

<matt> Bug 17199 - Provide examples for and get feedback on Key Release

markw: looking at the last comment.

<matt> Mark's proposal

markw: we had text in the original version, then we removed it for the OO API.
... a message attests that the key was destroyed
... use case is that an accurate record of how many streams the user has in progress at one time.
... we don't want you to have a thousand streams at once for subscription service.
... for EME the CDN creates these messages (origin specific).
... Need to store these messages, and you might send to the server.
... this can fail.
... need a signal from the server saying "yes I did recieve it"
... hense the requirement for the session id.
... then there are details on how to get the key release messagae.
... other case in 4.3 the media key is destroyed for another reason. We'd like to be able to see the keyrelease message relyably delivered.
... we know this may not be 100% of the time, but in practice, if a large percentage of these messages are recieved the server can mop up the rest.
... now in 4.5, proceedures for checking for stored messages on return to the app
... will create a media key session associated with the old state.
... skipping a few step details...

paulc: any questions?
... proposed replacement text for the bug resolution.
... any objections?

ddorwin: heard concerns about how you'd implement this.
... you'd need to save these to disk. Not sure if CNS would want to do this.
... and how to handle the 'navigate away' case. Not sure this system would be useful if that case isn't solved.

markw: on the first point (storage) the CDN needs some kind of storage. Either they support it or not.
... on the issue of browser-close--this is just an implementation challenge for UA.
... just another example of the general issue of responding to server without blocking the UA.
... Same problem as sync-XHR.
... would love an alternative to closing a session without hanging up the UI thread.

paulc: when the person navigates and it blocks.
... what's the UA behavior.

markw: it blocks.

ddorwin: ideas have been proposed about having it be synchronous.
... browsers are trending toward making things faster.

paulc: the server has all the info on the key sessions, and you'd like to clear it.

markw: the server has state that thinks the client is streaming.

pal: keyrelease message is not exceptional (it's a common req.)

ddorwin: there could be value for keyrelease message in other scenarios. Not sure if the req. for fully-reliable keyrelease makes sense.
... there are alternative options available.

paulc: markw do you see this as an optional feature?

markw: [nods]

paulc: so is this a V1?
... does anyone want to speak nay about adding this?

ddorwin: expiring licences and [other] are two other approaches
... you definately want to know when the licence is not being used anymore.
... we also have to make sure this is implementable.

paulc: are you suggesting we wait until an implementation?

adrianba: I agree with ddorwin
... the think I'm concerned about is specing it, but having know one implement
... sounds like marking a feature at risk and then seeing what happens later.
... we should review the proposal, highlight risks, etc.
... I don't object to this being in the spec.
... I don't think it's likely that we would implement (at first)
... If there are no implementation during our agressive schedule, then we probably wouldn't implement

markw: heartbeats model required a lot of interactions on the server, increasing the reqs. on the server.
... big difference on the server avaialbility (scalability)
... on browsers wanting to make shut-down faster, would love browser maker feedback.
... there are limits. You'd have to remove sync-xhr.
... it would be really valuable to remove sync-xhr, but don't break apps.

MediaKeys attachment is a method instead of property

<matt> s/topic:/issue:/

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

<ddorwin> http://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#extensions

adrianba: the model is to associate a media keys collection to a media element, we have a key attribute
... attribute MediaKeys keys;
... when you call the setter of keys, it makes the connection.
... (the bug we didn't get to asks where that binding means only one element maps to one key)
... problem is that it's not obvious (since it's a property) that there is processing that happens.
... I propose making this a method.
... also make the mediaKeys keys attribute be readonly for clarity that setting it is an active process.

paulc: any reactions?

ddorwin: "Make it so" TM

paulc: Adrianba to open a bug to fix it.

ddorwin: Media keys can be made and assigned to an element.
... it would also be bad for DOM tree ownership.
... I think this (single ownership) is a must.
... should have errors, etc., in order to make it so.

paulc: Chair secret--let the WG out early.
... current plan is that draft charter for EME will have not specific schedule (same for MSE)

artb: If folks want to take these specs and run with them, that's awesome! having too many timescales can lead to problems later on.

<adrianba> i think a similar timeline for EME and MSE is appropriate

paulc: calls for a recess until tomorrow.

- DRAFT -

HTML

01 Nov 2012

Attendees

Contents

Organization

Evolving AppCache

Responsive Images

Issue 195: Enhance HTTP request generation from forms

EME

MediaKeys attachment is a method instead of property

Summary of Action Items

Scribe.perl diagnostic output