08:58:08 RRSAgent has joined #mediafrag 08:58:08 logging to http://www.w3.org/2010/11/17-mediafrag-irc 08:58:10 RRSAgent, make logs public 08:58:10 Zakim has joined #mediafrag 08:58:12 Zakim, this will be IA_MFWG 08:58:12 I do not see a conference matching that name scheduled within the next hour, trackbot 08:58:13 Meeting: Media Fragments Working Group Teleconference 08:58:13 Date: 17 November 2010 08:58:33 zakim, list conferences ? 08:58:33 I don't understand your question, raphael. 08:58:36 zakim, list conferences 08:58:36 I see no active conferences and none scheduled to start in the next 15 minutes 09:08:57 erik has joined #mediafrag 09:17:03 I have made the request to generate http://www.w3.org/2010/11/17-mediafrag-minutes.html raphael 09:25:19 homata has joined #mediafrag 09:45:32 homata_ has joined #mediafrag 10:05:43 trackbot, start telecon 10:05:45 RRSAgent, make logs public 10:05:47 Zakim, this will be IA_MFWG 10:05:47 ok, trackbot, I see IA_MFWG()5:00AM already started 10:05:48 Meeting: Media Fragments Working Group Teleconference 10:05:48 Date: 17 November 2010 10:07:15 +Yves 10:08:04 + +33.4.93.00.aadd 10:08:06 zakim, who is there? 10:08:06 I don't understand your question, raphael. 10:08:10 zakim, who is here? 10:08:10 On the phone I see +49.408.081.7.aaaa, +44.329.331.aacc, Yves, +33.4.93.00.aadd 10:08:12 On IRC I see homata_, erik, Zakim, RRSAgent, raphael, tomayac, silvia, foolip, Yves, trackbot 10:08:28 zakim, +49 is tomayac 10:08:28 +tomayac; got it 10:08:39 zakim, +44 is erik 10:08:39 sorry, raphael, I do not recognize a party named '+44' 10:09:10 Agenda: http://lists.w3.org/Archives/Public/public-media-fragment/2010Nov/0029.html 10:09:38 I have made the request to generate http://www.w3.org/2010/11/17-mediafrag-minutes.html raphael 10:11:08 hamburg, germany, yes 10:11:38 Topic: 1. Admin 10:11:53 Present: Thomas, Yves, Erik, Raphael, Silvia (irc), Philip (irc) 10:12:00 Regrets: Davy 10:12:03 Chair: Raphael 10:12:11 Scribe: Raphael 10:12:15 Scribenick: raphael 10:12:29 PROPOSED to accept the minutes of the 7th F2F meeting: 10:12:29 - http://www.w3.org/2010/11/01-mediafrag-minutes.html 10:12:29 - http://www.w3.org/2010/11/02-mediafrag-minutes.html 10:12:41 ? 10:12:46 +1 (but am still reading it though :) 10:12:46 +1 10:12:57 pass ;-) 10:12:58 +1 10:13:05 minutes accepted 10:13:25 Topic: 2. Media Fragment Specification 10:14:10 For IBBT ... 10:14:28 ACTION-192? 10:14:28 ACTION-192 -- Davy Van Deursen to update the specification to state what the processing should do when media fragments request (time dimension) does not match exactly how the media item has been encoded -- due 2010-11-08 -- OPEN 10:14:28 http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/192 10:14:35 ACTION-193? 10:14:35 ACTION-193 -- Erik Mannens to make a schema for the server redirect recipe -- due 2010-11-08 -- OPEN 10:14:35 http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/193 10:14:41 ACTION-195? 10:14:41 ACTION-195 -- Davy Van Deursen to add a paragraph in the section 7.1 to specify that video, audio, img or any href is all treated similarly (range request issued when facing a media fragment) -- due 2010-11-08 -- OPEN 10:14:41 http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/195 10:14:48 ACTION-191? 10:14:48 ACTION-191 -- Yves Lafon to update the production rules of the time dimension with the npt format for making the hours optional -- due 2010-11-08 -- OPEN 10:14:48 http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/191 10:15:04 Yves started to do it during the f2f meeting, needs to add a sentence in the spec 10:15:19 ISSUE-19? 10:15:19 ISSUE-19 -- Parsing must be defined normatively in the MF spec itself -- open 10:15:19 http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/19 10:15:56 Philip has proposed a number of patches, see result at http://people.opera.com/philipj/2010/11/04/media-fragments-spec/overview.html 10:16:44 Yves has discussed this with Philip which sort of outdate this proposal 10:17:06 Yves: the result is that we should keep the grammar as it is, + some clarification text on the purpose of the grammar 10:17:41 ... + a normative algorithm for parsing 10:18:05 ... we need consensus and approval from Jack, Silvia, and Davy at least in the group + feedback from the implementers 10:18:46 is the proposal formally specified somewhere? 10:19:04 I'm probably ok with it but don't want to give a blind vote 10:19:20 Raphael: what this clarification text should express? 10:19:20 the purpose of the grammar is to describe the "normal" syntax, ie: the one that should be created 10:19:45 ie: it is not the parsing rules 10:19:56 Raphael: where we should write this ? 10:21:25 Yves: at the beginning of section 4 and appendix D 10:21:34 ... as a reminder 10:22:36 ACTION: raphael to add a clarification text regarding the purpose of the grammar 10:22:36 Sorry, couldn't find user - raphael 10:22:42 ACTION: troncy to add a clarification text regarding the purpose of the grammar 10:22:43 Created ACTION-199 - Add a clarification text regarding the purpose of the grammar [on Raphaël Troncy - due 2010-11-24]. 10:23:04 Raphael: regarding the parsing algorithm 10:23:26 Yves: back to a very detailed description of the algorithm 10:23:38 ... I would like to read it crisp and procedural 10:24:12 ... we need an agreement that the parsing algorithm become normative 10:24:53 ... I would agree that given this clarification of role, the algorithm become normative 10:24:59 Erik: I agree too 10:25:53 Silvia, would you have any objection of having a detailed parsing algorithm of a media fragment URI nomative in the spec instead of an annex? 10:26:30 Tow versions of the algorithm 10:26:33 ... 1/ http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-uri-syntax 10:26:37 s/Tow/Two/ 10:27:15 ... 2/ http://people.opera.com/philipj/2010/11/04/media-fragments-spec/overview.html#processing-name-value-components 10:27:33 ... and http://people.opera.com/philipj/2010/11/04/media-fragments-spec/overview.html#processing-name-value-components 10:28:06 ... and http://people.opera.com/philipj/2010/11/04/media-fragments-spec/overview.html#processing-name-value-lists 10:31:53 no objection here 10:33:46 Raphael: I agree to ask Philip to put which version he prefers 10:33:57 ... the only contentious issue might be: 2. 10:33:57 2. Otherwise, the name-value pair does not represent a media fragment dimension. Validators should emit a warning. User agents must ignore the name-value pair. 10:33:57 Note: Because the name-value pairs are processed in order, the last valid occurence of any dimension is the one that is used. 10:34:38 Raphael: Validators should perhaps emit an error rahter a warning ? 10:34:47 s/rahter/rather 10:35:26 ... the processing order of the dimensions and whether parsing should be relaxed or not in case of multiple occurences of the same dimension (except track) 10:36:23 ACTION: troncy to send a proposal to close ISSUE-19 that consists in: clarification text + normative parsing algorithm 10:36:23 Created ACTION-200 - Send a proposal to close ISSUE-19 that consists in: clarification text + normative parsing algorithm [on Raphaël Troncy - due 2010-11-24]. 10:36:41 I prefer my latest version that uses the namevalues syntax 10:37:06 great, thanks Philip, we will use this one then :-) 10:37:25 Topic: 3. Media fragments URI on web page 10:37:55 Raphael: started by a thread from Silvia 10:38:02 ... discussed at the F2F meeting: http://www.w3.org/2010/11/02-mediafrag-minutes.html#item05 10:38:33 ... lead to the notion of optimistic use if the Range header, only for the second unit 10:38:50 ... it cannot be done for any other way for getting part of the content 10:38:52 s/second/'second'/ 10:38:54 (except that my email was about something completely different ;-) 10:39:15 yeah I think Silvia's email was about using the html fragment for video 10:39:37 s/use if/use of 10:39:40 which by default is => no (ie: it's per page, so you can't generalize this) 10:40:14 it was not to become normative - the idea is to propose a syntax that people can choose to make use of 10:40:59 because the html URI is much more important for most video on the web than the video URI 10:43:45 Yves: there are 2 orthogonal issues 10:44:00 ... the fragment applies to ONE resource you're retrieving 10:44:24 ... if you want the fragment on the page be applied to the video element on that page, this is your javascript that can do that, nothing to put in the spe 10:44:27 s/spe/spec 10:45:30 ... the other issue of optimistic use of the Range header, Philip states that this is up to the URI spec to change 10:45:37 ... I quote: "The semantics of the fragment identifier is defined by each MIME type registration. Before we know the type, we can't assume anything. Therefore, the only possibility is if the URL/URI/IRI spec itself states that #t=1 has some semantics for *all* types and that this should cause headers Foo and Bar to be sent. However, I truly doubt we'll see media-specific things like this put into URL/URI/IRI, it's seems like a gigantic layering violat 10:46:21 as I said: the idea is to give a Web developer that wants to do media fragments on a Web page a recommendation for how to do the URI structure on their page - they still have to implement it themselves, it's just handy to agree on the same approach 10:46:57 no need for more Range headers, or an implementation in browsers or anything - just a helping hand for Web developers 10:46:58 Raphael: I agree silvia, and I strongly recommend to add a new Appendix for what you propose, note to developers :-) 10:48:00 Agreed, as long as there's no change in UA behavior for #t=1 for HTML I'm fine with recommending web developers to use the syntax 10:48:10 btw: all the video hosting sites already have such approaches in the URIs so it's not theoretic 10:48:37 I agree that we can't assume anything, and we shouldn't break any layer, but if we know enogh context, using Range request with a unit that can only be applied to the media type we are targeting (and will default to normal behaviour for all the others) 10:48:45 Silvia, would you like to have an action to write a paragraph, note to developers, that they can easily implement a javascript to forward the hash on the URI to the video element? 10:48:58 is a (not nice) possible optimisation 10:49:00 yup, no problem 10:49:06 just don't know when I'll get around to it :) 10:49:23 context should be that URI is in a