See also: IRC log
<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> is the link to the wiki for Face to Face topics
<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
... 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?
... 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
... 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
... 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?
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?
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.
<trackbot> ISSUE-195 -- Enhance http request generation from forms -- open
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
... One of the media groups, can't remember which --
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.
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
... 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?
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
... 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
... 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.
-> 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
... 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?
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
... 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?
ArtB: 8 said WebApps WG, 1 said
(darobin) HTML and another had strong preference for a
... 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
... 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.
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
<krisk> scribe: krisk
We are about to get started on the responsive images
<pal> pbakaus has joined #html-wg
mjs: see the pasted in link above
mjs: two drafts for the use
... 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
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
marcos: another use case is
... 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_,
... 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
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
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
... 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
<hsivonen> yoav weiss
yoav: you can see as the browser
is resized the network trace shows getting the right image
... 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
... 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
pal: have you looked at CSS for solutions?
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
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
... 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
cyns you are on the q
<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
... 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
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: 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
... 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...
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
..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
next discusson: Isssue 195
<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
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
... 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
... 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
... 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
... it's not simple as saying XHR is safe:
cabanier: this stuff was added
for UAs that has not CORS support, etc..
... it just about basic html
..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
... 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
... 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
<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: 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?
<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
... 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
... any q/c? on this proposal?
plh: asks how one gets
... see 4.8.9 defines HTMLTrackElement
<matt> Track Element
<matt> video element
travis: HTMLTrackElement has ID, but TrackElement does not
<tantek> so this is the trackid
<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
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: when using media source, about what fields should return
scribe: need to be clearer about which ids are used
cyril: can't just copy id from
... 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
... 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
... 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
... 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
acolwell: should not require
... pat/pmt in TS proposal is considered initialization segment
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
acolwell: remove conflict
<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
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
... 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
... 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
acolwell: use XHT to append data?
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?
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
paulc: bug 18963
adrianba: should there be
mechanism to inform app it is appending data faster than being
... 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
... 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
... bug 18709 - remove [data] method
scribe: what if remove on current
... if data gets appended over playback position, then what?
... stay paused? seek?
... 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
... 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?
<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
paulc: bug 17002
adrianba: mechanism for mapping
track object against html media element back to source
... 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
... 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
... 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
<BobLund> I've got to leave at half past the hour.
<matt> EME bugs
paulc: looking into the priorized
list of EME bugs
... look at the attachment in Paul's mail link
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
... 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
... 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
... 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
... 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?
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
... 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.
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
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
... 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.
<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
... we also want examples for ISO and webM cases with a presumed same container.
Markw: JSON webkey doesn't yet
... 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
... then from CR->PR and upon registry, then it can come out (very late)
paulc: looking at bug 17470
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
... 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.
markw: in the threads there are
... 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
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
... 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...
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.
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]
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?
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
... 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
... 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.
adrianba: the model is to
associate a media keys collection to a media element, we have a
... 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
... 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.
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/??/hober/ Succeeded: s/@@bugs@@/there are several interrelated bugs on the hidden="" section, which we'll probably address all at once/ Succeeded: s/??/Cameron/ Succeeded: s/after coffee/before coffee/ Succeeded: s/???/what about the bug 18971 Text track should have an id/ Succeeded: s/??/acolwell/ Succeeded: s/??/acolwell/ Succeeded: i/scribe: Matt/Topic: Organization Succeeded: s/paulc/mjs/ Succeeded: s/coordination group/community group/ Succeeded: s/Chris/Kris/ Succeeded: s/Chris/Kris/g Succeeded: s/sessions/session/ Succeeded: s/bandwitdth/bandwidth/ FAILED: s/???/Yoav/ Succeeded: s/pal/???/ Succeeded: s/???/pbakaus/ FAILED: s/fligth/fight/ Succeeded: i/scribe: krisk/Topic: Responsive Images Succeeded: s/who os here?// Succeeded: s/who is here?// Succeeded: s/??: MSE/acolwell: MSE/ Succeeded: s/#join #ac rhone// Succeeded: s/..new/... new/ FAILED: s/..maybe/... maybe/ FAILED: s/..we/... we/ FAILED: s/..another/... another/ FAILED: s/..the addition/... the addition/ FAILED: s/..given/... given/ FAILED: s/cyri/cyril/ FAILED: s/Isssue/Issue/ FAILED: s/cabanier/cjones/ FAILED: s/member:cabanier: the changes /cjones; the changes/ FAILED: s/cabanier: the changes /cjones; the changes/ FAILED: s/cabanier: we are proposing/cjones: we are proposing/ FAILED: s/cabanier: it's a black list/cjones: it's a black list/ FAILED: s/cabanier: the changes involved/cjones: the changes involved/ Succeeded: s/feature/features/ FAILED: s/infobot inform plh radio check// FAILED: s/but TrackElement/but TextTrack/ Succeeded: s/.../paulc:/ FAILED: s/est ~2wks/est ~2wks before the CfC/ Succeeded: s/robin/darobin/ FAILED: s/fields/id fields/ FAILED: s/MSE, API is/MSE as an API/ WARNING: Bad s/// command: s/pat\/pmt/PAT\/PMT/ FAILED: s|pat/pmt|PAT/PMT| FAILED: s|pat/pmt|PAT/PMT| FAILED: s/adrianba:/acolwell:/ FAILED: s/on MS?/on MSE?/ FAILED: s/XHT/XHR/ FAILED: s/a presentation occupancy/a buffer occupancy/ FAILED: s/data/time ranges/ FAILED: 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 FAILED: s/tha twork/that work/ FAILED: s/published dates/CR and PR dates/ FAILED: s/aggressive on work/agressive on LC/ FAILED: s/masinter:// FAILED: i/scribenick: glenn/Topic: Media Source Extension FAILED: s/WebTV XG/Web and TV IG/ FAILED: s/commen/common/ FAILED: s/JSON/JSON Web Key/ FAILED: s/elaborage/elaborate/ FAILED: s/topic:/issue:/ Found Scribe: Matt Inferring ScribeNick: matt Found Scribe: krisk Inferring ScribeNick: krisk Found ScribeNick: glenn Found ScribeNick: Travis Scribes: Matt, krisk ScribeNicks: matt, krisk, glenn, Travis WARNING: Replacing list of attendees. Old list: Cynthia_Shelly Rhone_3 SteveF [IPcaller] New list: Rhone_3 Steve Cynthia_Shelly BobLund Clarke Default Present: Rhone_3, Steve, Cynthia_Shelly, BobLund, Clarke Present: Rhone_3 Steve Cynthia_Shelly BobLund Clarke Arnaud_Braud kris_krueger Philippe Le Hegaret Adrian_Bateman Erika_Doyle_Navara Matt Wonsuk__Lee jgraham MikeSmith pal hober MartinSoukup Marcos ddorwin acolwell r12a glenn Magnus_Olsson yoav_ fwtnb johnsimmons markw__ wiltzius hBang Stevef Jonathan_Jeon dan_romascanu Yi-Jen Art_Barstow Tomoyuki_Shimizu sgodard 1 Paul Cotton krisk /me Cyril SteveF nkic Johnsimmons Glenn_Adams Mark_Vickers Agenda: http://www.w3.org/html/wg/wiki/TPAC2012#Agenda Got date from IRC log name: 01 Nov 2012 Guessing minutes URL: http://www.w3.org/2012/11/01-html-wg-minutes.html People with action items: glenn paulc WARNING: Possible internal error: join/leave lines remaining: <pal> pbakaus has joined #html-wg <darobin> dadarobin has joined #html-wg WARNING: Possible internal error: join/leave lines remaining: <pal> pbakaus has joined #html-wg <darobin> dadarobin has joined #html-wg[End of scribe.perl diagnostic output]