07:56:20 RRSAgent has joined #mediafrag 07:56:20 logging to http://www.w3.org/2009/04/16-mediafrag-irc 07:56:22 RRSAgent, make logs public 07:56:22 Zakim has joined #mediafrag 07:56:24 Zakim, this will be IA_MFWG 07:56:24 ok, trackbot; I see IA_MFWG()3:00AM scheduled to start 56 minutes ago 07:56:25 Meeting: Media Fragments Working Group Teleconference 07:56:25 Date: 16 April 2009 07:56:31 zakim, code? 07:56:31 the conference code is 3724 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), jackjansen 07:57:58 IA_MFWG()3:00AM has now started 07:58:06 + +34.93.401.aaaa 07:59:47 - +34.93.401.aaaa 07:59:49 IA_MFWG()3:00AM has ended 07:59:49 Attendees were +34.93.401.aaaa 08:00:21 to fill you in: we can physically call, but we may run into trouble with uni burocracy here. 08:00:28 Will try something else. 08:01:20 Silvia, you can use the phone number and code above 08:01:26 ... but you will be alone on the phone 08:01:31 we will phone through skype 08:01:42 but get the mic and speaker from a laptop 08:02:04 interim solution till lunch, when we hope to talk to MIT guys that can call us 08:02:38 yves: is the thing that needs to be done at MIT a one-time action? i.e. if they do the magic later today, will we be able 08:02:45 ... to use the speakerphone tomorrow morning? 08:02:59 jack; I will ask what is possible 08:09:46 zakim, code? 08:09:46 the conference code is 3724 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), jackjansen 08:10:17 IA_MFWG()3:00AM has now started 08:10:23 +??P0 08:10:33 we R in! 08:10:37 zakim, ??P0 is all of us in the meeting room. 08:10:37 I don't understand '??P0 is all of us in the meeting room', jackjansen 08:10:39 zakim, ??P0 is Barcelona_Room 08:10:39 +Barcelona_Room; got it 08:10:44 zakim, get a life! 08:10:44 I don't understand 'get a life!', jackjansen 08:10:55 zakim, you failed the turing test. 08:10:55 I don't understand 'you failed the turing test', jackjansen 08:11:10 + +61.2.801.2.aaaa 08:11:11 Zakim, how is Ralph doing? 08:11:11 I don't understand your question, mhausenblas. 08:12:59 Agenda: http://www.w3.org/2008/WebVideo/Fragments/wiki/ThirdF2FAgenda 08:13:06 RRSAgent, draft minutes 08:13:06 I have made the request to generate http://www.w3.org/2009/04/16-mediafrag-minutes.html raphael 08:13:42 Chair: Erik, Present 08:14:13 s/Present/Raphael 08:15:12 Present: conrad, michael, jack, erik, davy, frank (canon observer), raphael, dave singer, silvia (phone), yves (phone) 08:15:20 Scribe: raphael 08:15:27 Scribenick: raphael 08:15:32 I have made the request to generate http://www.w3.org/2009/04/16-mediafrag-minutes.html raphael 08:16:39 Topic: 1. Administrative 08:16:58 Agenda is at: http://www.w3.org/2008/WebVideo/Fragments/wiki/ThirdF2FAgenda 08:17:15 Chairs would like to ammend the agenda, and start with a proposal to publish our FPWD 08:17:43 ... needs the group approval 08:20:57 Silvia: I think I have corrected all the markup errors 08:21:10 +1 08:21:36 PROPOSAL: publish the document at http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/ as a first public working draft 08:21:39 Any objections ? 08:21:55 no objections - publication approved 08:22:01 no objections 08:22:02 no objections 08:22:04 no objections 08:22:04 no objections 08:22:07 no objections 08:22:13 dsinger has joined #mediafrag 08:22:18 no objections 08:22:34 Please, dave, so you have any objections to publish http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/ as a FPWD? 08:22:41 FD has joined #mediafrag 08:23:05 no, we can publish and continue to revise, that's fine 08:23:11 I mean, no objections 08:23:25 same :) 08:23:38 RESOLUTION: The Media Fragments agree to publish its FPWD 08:23:47 I have made the request to generate http://www.w3.org/2009/04/16-mediafrag-minutes.html raphael 08:24:12 Topic: 2. Yves/Silvia/Conrad: Specification discussion 08:24:13 * discuss the story of the single-step vs dual-step partial GET (aka 2-ways, 4-ways handshake); 08:24:13 o discuss the Silvia's proposal: new headers Accept-TimeURI, Accept-SpaceURI, Accept-TrackURI and Accept-NameURI; 08:24:13 o discuss Yves's proposal: a GET of the media header (so a few bytes, depending on how much is enough), and the server answers with that + one or more Link: headers linking to different mappings (time to bytes is an example) or at least a resolver URI, linking to the sub-resource, to parent etc... 08:24:14 o discuss the pro/cons of each solution 08:24:16 * check with the evolving link header draft; 08:24:19 * Yves: present the clarifications of HTTPBis. 08:24:20 I have detailed comments, I'll try to get them to the group over these two days 08:25:57 zakim, who is here ? 08:25:57 On the phone I see Barcelona_Room, +61.2.801.2.aaaa 08:25:58 On IRC I see FD, dsinger, Zakim, RRSAgent, conrad, raphael, mhausenblas, davy, jackjansen, erik, silvia, Yves, trackbot 08:26:06 Yves, can you call to hear us ? 08:26:08 we are on the phone 08:26:21 zakim, aaaa is Silvia 08:26:21 +Silvia; got it 08:26:59 +Yves 08:27:21 blog: http://blog.gingertech.net/2008/11/10/media-fragment-uri-addressing/ 08:27:50 read the last comment - FYI 08:29:30 Yves: we need to clarify, in the dual step partial GET, how the resolution between time ranges and bytes work 08:29:45 Silvia: the WD now explains how it works 08:30:51 Yves is reading http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/#dual-step 08:31:34 Yves: there is something wrong in the first reply, you have a Content-Range but a 200 OK response 08:33:29 ... if there is a Content-Range header, it should be a 206 response 08:35:36 Michael, I think a 100 response means the server sends something, and then something else but no interaction from the UA in the middle 08:35:45 ... while in our case the UA remakes its request 08:36:16 Michael: I agree with silvia re caching header but not caching the entire message for scalability reasons 08:37:06 Yves: first concern should be on user experience rather than caches/proxies efficiency .... they would anyway tune the right way the softwares 08:37:21 not sure, raphael re 100 response is totally out of question 08:37:49 Yves? what's your opinion on this? 08:38:51 Silvia: for spatial fragments, there is no way we can cache things anyway 08:39:08 Yves: I'm not sure we should forbid transcoding 08:39:27 ... I would ask for more people 08:39:29 q+ to note that caching temporal fragments is *much* more interesting that spatial fragments 08:41:19 Silvia: your problem seems to be that there is 2 requests 08:41:25 ... TBL had the same feeling in Cannes 08:41:35 q- 08:42:18 ... but the first request has no real data, so no delay 08:42:42 correction: but the first request retreives real data, so it is not unnecessary 08:43:15 Yves: I would approach some TAG members informally 08:43:59 so having two HTTP request/response cycles does not introduce noticeable overhead in retrieving large amounts of data 08:44:22 Yves: headers+keyframes are not fake data 08:44:37 they are, as they are not part of the resource representation 08:45:08 Yves, i respectfully disagree, they are a necessary part of the segment representation 08:45:26 ACTION: Yves to ask the TAG whether transcoding should be forbidden or not when we send a fragment of a resource 08:45:26 Created ACTION-62 - Ask the TAG whether transcoding should be forbidden or not when we send a fragment of a resource [on Yves Lafon - due 2009-04-23]. 08:45:28 of the segment, yes, but not the whole resource, which is addressed by the first get :) 08:45:55 plus there may be a mismatch of content between the first and second request 08:46:05 Jack: the current WD does not say which anwsers has headers data and which ones has just headers 08:46:47 Conrad: let me explain how things will work 08:47:31 ... I tend to see that the dual step is just a fallback of the single step 08:47:58 I have made the request to generate http://www.w3.org/2009/04/16-mediafrag-minutes.html raphael 08:49:14 davy has joined #mediafrag 08:49:30 Conrad's schema: 08:50:29 -Barcelona_Room 08:50:46 Conrad: user request URL = http://www.example.com/video.ogg?t=10,20 08:50:53 -Silvia 08:51:18 I have made the request to generate http://www.w3.org/2009/04/16-mediafrag-minutes.html raphael 08:51:34 erik has joined #mediafrag 08:51:50 jackjansen has joined #mediafrag 08:51:56 We lost our network. 08:52:00 And our phone. 08:52:05 Time for coffee. 08:53:52 -Yves 08:53:54 IA_MFWG()3:00AM has ended 08:53:55 Attendees were Barcelona_Room, +61.2.801.2.aaaa, Silvia, Yves 08:58:14 raphael has joined #mediafrag 08:59:34 Yves: in temporal URI for annodex, we only used ? for remote retrievals - # was done locally only in the client 08:59:51 trackbot, start teleco 08:59:51 Sorry, raphael, I don't understand 'trackbot, start teleco'. Please refer to http://www.w3.org/2005/06/tracker/irc for help 08:59:54 trackbot, start telecon 08:59:56 RRSAgent, make logs public 08:59:58 Zakim, this will be IA_MFWG 08:59:58 ok, trackbot; I see IA_MFWG()3:00AM scheduled to start 119 minutes ago 08:59:59 Meeting: Media Fragments Working Group Teleconference 08:59:59 Date: 16 April 2009 09:00:20 Yves with ? you have no problem, you just return the whole fragment with header as a response to the GET, no need to to anything extra 09:00:36 Yves: as ...?t=1,2 is different form ?t=2,3 and won't be cached as the same resource by caches anyway 09:00:48 I have made the request to generate http://www.w3.org/2009/04/16-mediafrag-minutes.html raphael 09:01:45 Conrad: back to the explanation, I explain how temporalURI works 09:02:42 foolip has joined #mediafrag 09:03:38 hi all 09:04:34 I browsed through http://www.w3.org/2008/WebVideo/Fragments/wiki/ThirdF2FAgenda but couldn't figure out which parts were on teleconf 09:05:41 would be nice if the next F2F were in Stockholm, since I live not too far from there :) 09:05:43 this is the agenda for the 2 days, we are now on the first topic: Specification discussion 09:07:55 Zakim, what's the code? 09:07:55 the conference code is 3724 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), mhausenblas 09:08:06 IA_MFWG()3:00AM has now started 09:08:13 +[IPcaller] 09:09:06 zakim, +[IPcaller] is Barcelona_Room 09:09:06 sorry, raphael, I do not recognize a party named '+[IPcaller]' 09:09:22 zakim, +IPcaller is Barcelona_Room 09:09:22 sorry, raphael, I do not recognize a party named '+IPcaller' 09:09:30 zakim, IPcaller is Barcelona_Room 09:09:30 +Barcelona_Room; got it 09:09:55 davy has joined #mediafrag 09:10:24 -Barcelona_Room 09:10:24 +Barcelona_Room 09:10:24 +Yves 09:11:01 Zakim, who is here? 09:11:01 On the phone I see Barcelona_Room, Yves 09:11:02 On IRC I see davy, philipj, raphael, jackjansen, erik, FD, dsinger, Zakim, RRSAgent, mhausenblas, silvia, Yves, trackbot 09:11:05 Conrad agree with Yves's point 09:11:11 Re: ? vs # 09:11:30 Conrad will continue his explanation of TemporalURI 09:12:27 Conrad: URL = http://www.example.com/video.ogv?t=10,20 09:12:36 ... Client do a GET URL 09:12:52 ... with a new header: Accept-Range-Refer: bytes 09:13:19 ... Server: it udnerstands the range referal 09:13:28 ... will answer a 200 OK 09:14:02 ... with new headers: Range-Refer: this, 0-1000 09:14:04 http://www.example.com/video.ogv?t=10,20 is a plain URI, unrelated to http://www.example.com/video.ogv. Why not serving the content directly? 09:16:48 good question :-) 09:17:38 Conrad: ... Range-Refer: URL2, a-b 09:17:50 ... Vary: Range-Refer and the body 09:18:07 Client: will make another GET URL-2 request with the range a-b 09:20:27 Jack: in the case the server does not understand the ?t=10,20 ... it will answer a 404 09:20:49 will answer with a 404... that depends on the server configuration 09:20:59 ... while in the case the server does not understand the #t=10,20 the way we want, it will send the whole resource, better for the UA 09:21:15 in some cases the ? will be ignored and you will save in a cache 100+ times the full content (attached to different URIs) 09:22:16 Yves: this is a URI the server does not know about ... how can it be different from a 404 ? 09:22:54 raphael, try to access http://www.w3.org/ and http://www.w3.org/?foo=bar 09:23:06 that example work with lots of other servers ;) 09:23:39 well done :-) 09:24:15 so accessing http://media.exampe.com/bigvideo.mp4 http://media.exampe.com/bigvideo.mp4?t=1,2 09:24:22 will cache twice the big content 09:24:31 unrecognized query strings will almost certainly be ignored by most servers, not return 404 09:24:42 all because of a quite common server configuration issue 09:25:04 (as the right thing would be to return a 404) 09:25:10 ok. So people shouldn't issue ? temporal uris to non-capable servers. 09:25:29 jack, yes, basically you need to know in advance 09:26:04 sounds rather unreliable 09:26:12 yep 09:26:33 btw, is it worth saying things on IRC or do I need to join by phone? I happen to not have a phone nearby. 09:27:07 I still think that if you have http://media.example.com/media?t=1,10 should return the fragment with the header as a complete resource 09:27:25 might also want to take http://www.w3.org/2001/tag/doc/whenToUseGet.html#safe into consideration ... 09:27:35 FD has joined #mediafrag 09:27:42 Yves, haha, ok then 09:29:53 yep, this is what Conrad said too ! 09:30:34 Yves: fragment + header meaning a complete resource 09:30:55 Conrad: we will just ONE round trip, and a 200 OK in the case of a capable server understanding temporalURI 09:31:12 ... what is the fallback plan? 09:31:36 how can one detect if the server does not understand temporalURI? 09:32:16 sorry, I will be afk for lunch 09:33:28 wondering why the server shouldn't just send a 501 http://tools.ietf.org/html/rfc2616#section-10.5.2 09:33:56 Conrad answer: in temporal URI, the client uses another header: Accept-TimeURI 09:33:56 mhausenblas, in which case? 09:34:23 what philipj was asking and we are discussing here, now (server does not understand temporalURI?) 09:34:45 ... further: the header in the ogg file returned will contain a In-point=10, so the client knows he didn't get the full resource, but this is media format dependant 09:35:02 ... it will work for ogg, perhaps for mp4, but certainly not for avi for example 09:35:45 or, how are odds that HTTPbis will introduce a new code for that case ... 09:36:08 Yves, yes I guess you are right, so just for the record, 501 is NO option, right? 09:36:40 (I was wondering if you meant "if the server doesn't know how to handle it, it should reply with a 501', which is againt the 'ignore what you don't understand' paradigm) 09:36:48 so yes 501 is not an option 09:37:22 Raphael: let's kick out the ? for now, and work on the # 09:37:39 s/wich is againt/which is against 09:37:55 Jack: our premises are that the client are easy to modify, while your asumption is that you think we should adop servers 09:38:04 +1 to raphael's proposal to focus on the # 09:38:13 s/wich is againt/which is against 09:38:54 if the # implies client sending a range request, then the server would do the work 09:39:14 raphael: is drawing a table 09:39:18 and the client will do the work as a fallback 09:39:32 the intention is to capture/structure the current state 09:39:49 Scribenick: mhausenblas 09:40:32 raphael: two cases at the table 09:41:01 ... either the UA makes a request using a unit like sec which is transformed into range request 09:41:19 ... and the server knows how to handle the mapping 09:41:32 David agrees so far 09:41:49 raphael: the second case is where we need a resolver 09:42:24 David again on the board 09:43:14 s/David/Conrad 09:43:41 s/David agrees so far/Conrad agrees so far 09:43:52 rrsagent, draft minutes 09:43:52 I have made the request to generate http://www.w3.org/2009/04/16-mediafrag-minutes.html mhausenblas 09:45:32 Conrad: client - GET URL, Aceept-TimeURI, Media-Fragment: t=10,20 09:46:12 ... Server: 206 partial content (with body, H' + K + D2) 09:47:21 For the people not in the room: the original media is H + D1 + D2 + D3 09:47:22 and Server: Content-Range: in sec and bytes (?) 09:47:41 ... D1 is seconds 0-10, D2 10-20, D3 20-30. 09:48:08 ... H' is modified header, K is synthetic keyframes etc. to be able to interpret D2 correct. 09:49:27 Conrad: let's assume the URI is .../video.ogg#t=smpte-25:00'10.23.25, 09:49:45 ... hence we need to specify the unit in the Range 09:51:25 raphael: if we specify the unit in the Range, we can agree on that? 09:51:48 davy_ has joined #mediafrag 09:52:32 jackjansen: I ran into the same issue when implementing it 09:53:31 -Barcelona_Room 09:53:50 I have made the request to generate http://www.w3.org/2009/04/16-mediafrag-minutes.html raphael 09:55:25 jackjansen has joined #mediafrag 09:56:43 +??P0 09:56:45 -??P0 09:56:45 +??P0 09:57:00 zakim, who is here? 09:57:00 On the phone I see Yves, ??P0 09:57:01 On IRC I see jackjansen, davy, FD, philipj, raphael, Zakim, RRSAgent, silvia, Yves, trackbot 09:57:13 mhausenblas has joined #mediafrag 09:57:16 Yves, we are back 09:57:56 erik has joined #mediafrag 09:57:57 raphael: sums up last 5min 09:58:34 a new header won't trigger partial responses 09:58:34 raphael: Conrad suggests to introduce a new header and let the server do the magic 09:59:27 the right way would be in this case to do conneg and point to a CL and a Vary, but in that case we mandate multiple URIs, and defeat caches again ;) 09:59:41 Conrad: this was my first issue with Range: 09:59:45 ... now second 10:00:00 (scribe notes that we have not yet fully resolved this issue) 10:00:28 Yves, in *which* case - new header? 10:00:47 if a new Media-Fragment: header is introduced in place of Range 10:00:59 ok, thanks for the clarification 10:01:56 Conrad drawing UA - Proxy - Original Server 10:02:06 raphael has joined #mediafrag 10:02:39 +Silvia 10:03:37 Michael: note what 206 (http://tools.ietf.org/html/rfc2616#section-10.2.7) says about caching ... 10:05:03 michael, see also http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-06 10:05:32 ta, Yves, was hoping that you come up with a recent state ;) 10:06:00 is there a big difference? 10:06:06 no small clarifications only 10:06:31 in rfc2616, the text was open to new units, but without any way of doing it, in httpbis it has been clarified 10:09:46 Yves: summary, we understand the concern of Conrad: single step partial GET, with a 206 response works, but it is not cachable 10:09:53 ... which we know, written in 7.3 ! 10:10:08 Michael: are we seeking a trade-of between cachability and round-trip? 10:10:09 in current web proxies not cachable 10:10:13 jackjansen: yes 10:10:16 Conrad: no 10:12:50 jackjansen: let' ignore the No-Cache for now, different issue 10:12:51 things we can add is a header in the reply indicating where D2 is and its relationship to bytes in the original file 10:14:00 I agree with the addition of such a header 10:15:56 jackjansen: we should optimise for the case where a URI is embedded in an Web page 10:18:30 silvia: for example in youtube case, each time you click on a time-offset it's a different URI 10:18:59 jackjansen: do I understand correctly: every time I click on it I get a new URI? 10:19:02 silvia: yes 10:19:58 raphael: let's move on 10:20:19 ... we seem to agree on the one-step process but the cachable part 10:21:17 in the YouTube case there is a special server and a proprietary client - we cannot really tell what is going on; but when you click on an offset, a new connection is opened and new buffering is started 10:22:46 jackjansen: a super-clever proxy would cache the entire bits and handle the parts accordingly 10:23:12 and a not so clever proxy could return the same content when the same second range is requested 10:23:22 yes Yves 10:23:41 'second' or 'other unit then bytes' 10:23:47 Conrad would like to move on the 4-ways handshake 10:24:13 but ading a mapping header in the reply (if possible would be a good thing, and only 'informative', so nothing mandatory to implement on the receiving end 10:24:34 gui walks in 10:24:41 I agree with Yves 10:24:43 and that would help a lot Silvia and Conrad's use case 10:24:48 Guilleaume has arrived 10:25:01 s/ading/adding/ 10:25:26 +1 for Yves 10:25:37 +1 as well from me 10:27:09 Conrad: I don't think doing 200 response or 206 response should be our goal 10:27:35 ... my solution will add new headers on the client side but would be pretty similar 10:28:12 Conrad now explains now his solution with # and no Range 10:28:15 I will take a picture of Conrad complet's proposam 10:28:24 s/proposam/proposal 10:28:35 rrsagent, draft minutes 10:28:35 I have made the request to generate http://www.w3.org/2009/04/16-mediafrag-minutes.html mhausenblas 10:30:29 Conrad: GET URL, Accept-Range-Refer: bytes, Media-Fragment:t=10,20 10:31:39 Server: 200 OK, body Hi+K+D2 10:32:39 ... and additionally a header in the response ... Content-Media-Fragment:t=10,20 10:32:59 (it's raining) 10:33:52 dsinger has joined #mediafrag 10:37:03 Conrad: Range-Refer: this, 0-1000 10:37:19 note that 'this' is meant verbatim 10:38:20 Conrad: continuing Range-Refer: URL2, Varu: Range-Refer, body 10:38:45 jackjansen: let's not use 'this' but just blank (?) 10:39:11 ping 10:40:23 (we seem to agree to disagree) 10:41:03 raphael: see no big difference between Conrad's proposal and what is in the current draft 10:41:21 right 10:41:33 Yves is leaving 10:41:40 -Yves 10:43:36 PIctures are in http://www.w3.org/2008/WebVideo/Fragments/meetings/2009-04-16-f2f_barcelona/ 10:43:38 jackjansen: we should structure the document in the fall-back flow 10:44:22 ... much easier to grock, then 10:44:27 Michael: +1 10:45:48 Silvia: can we modify the current draft and enhance it with Conrad's proposal? 10:45:58 raphael: still need to understand better 10:46:45 is the proposal to allow either or both of these methods? 10:47:32 conrad's single and dual step GET 10:48:47 IIUC the one-step GET is preferrable, but it doesn't work with existing Web proxy caching infrastructure other than by keeping multiple copies; the two-step GET is for making media fragment URIs work with existing caching Web proxies 10:49:19 raphael: re philipj's question, its a fallback-stack 10:49:45 I see 10:54:49 raphael: in most of the cases, URL and URL2 are identical 10:55:08 (scribe notes also that there are two or more servers involved) 10:55:24 davy has joined #mediafrag 10:56:33 -Barcelona_Room 10:56:35 where does a and b come from? are they 0 - 1000 ? 10:56:39 -Silvia 10:56:41 IA_MFWG()3:00AM has ended 10:56:42 Attendees were Barcelona_Room, Yves, Silvia 10:57:32 I have made the request to generate http://www.w3.org/2009/04/16-mediafrag-minutes.html raphael 10:58:56 jackjansen has joined #mediafrag 10:59:45 mhausenblas has joined #mediafrag 10:59:48 raphael: before lunch two questions 11:00:34 ... (1) for me the UA does not know that it has to do another request 11:01:16 and these will be discussed/ansewered after lunch 11:02:20 jackjansen: is the more general approach of Conrad worth it re the introduced complexity which is apparently much higher 11:02:29 +1 11:03:22 ACTION: Conrad to update the Wiki with his more general approach with precisely the same exmples 11:03:22 Created ACTION-63 - Update the Wiki with his more general approach with precisely the same exmples [on Conrad Parker - due 2009-04-23]. 11:03:25 I still do not understand the different 11:03:33 yes, please :) 11:04:09 time for lunch. Silvia: will you still be here later? 11:04:23 sorry, silvia you will have to wait a bit - Conrad suggests to read his blog ;) 11:04:37 we will be back in roughly an hour 11:04:54 ok, I may not be back 11:05:18 I'm rather tired tonight and the phone is really exhausting 11:05:22 but I will linger here 11:05:39 I read the blog, which I found just as confusing :) 12:25:29 Zakim has left #mediafrag 12:29:35 trackbot, start telcon 12:29:37 RRSAgent, make logs public 12:29:37 Zakim has joined #mediafrag 12:29:39 Zakim, this will be IA_MFWG 12:29:39 ok, trackbot; I see IA_MFWG()3:00AM scheduled to start 329 minutes ago 12:29:40 Meeting: Media Fragments Working Group Teleconference 12:29:40 Date: 16 April 2009 12:59:38 erik has joined #mediafrag 12:59:56 raphael has joined #mediafrag 13:00:10 I have made the request to generate http://www.w3.org/2009/04/16-mediafrag-minutes.html raphael 13:01:57 philipj has joined #mediafrag 13:03:08 davy has joined #mediafrag 13:03:56 yeahhhhhhhhhhhhhhhh 13:05:24 dsinger has joined #mediafrag 13:05:54 FD has joined #mediafrag 13:07:33 davy has joined #mediafrag 13:12:13 Zakim, what's the code? 13:12:13 the conference code is 3724 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), mhausenblas 13:12:23 IA_MFWG()3:00AM has now started 13:12:30 +[IPcaller] 13:12:40 zakim, IPcaller is Barcelona_Room 13:12:40 +Barcelona_Room; got it 13:13:43 +Yves 13:18:04 FD has joined #mediafrag 13:18:20 raphael: Yves please update us on HTTP Link: header 13:19:21 conrad has joined #mediafrag 13:20:36 raphael, are you reffering to http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-06 ? 13:21:07 yes 13:22:19 "If a range unit is not understood in a request, a server MUST ignore 13:22:19 the whole Range header" 13:24:13 url for link header draft? 13:24:57 Michael: see http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0189.html for updates on HTTP Link: 13:25:05 http://tools.ietf.org/html/draft-nottingham-http-link-header-04 13:26:51 jackjansen: if only partially available? say file is 100bytes, and I request 50 - 150, it will be cut of at 100? 13:26:54 Yves: yes 13:27:23 jackjansen: all our replies should hence also incl. the time range, not only the bytes 13:28:17 raphael: we will also have to be more precisely in the edge cases handling and their explanation 13:28:38 if you always get 200 you won't get fragments :) 13:29:02 http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-06#section-3.2 13:29:06 is actually unit-agnostic 13:29:27 yep, I phrased that wrongly 13:29:32 "none of the 13:29:32 ranges-specifier values in this field overlap the current extent of 13:29:33 the selected resource" 13:30:40 In Conrad's proposal, in the case of the dual-step partial GET, the second request is still a normal Range request, so will get the normal 206 (or 416) response code 13:31:19 ... only the first request will be answered by a 200 OK response, since it contains just the header + key frames data in the body 13:31:49 jackjansen: so, if the query would be empty in any of the dimension, the result would be a 416 13:32:27 http://www.w3.org/2008/WebVideo/Fragments/meetings/2009-04-16-f2f_barcelona/ 13:33:07 http://blog.kfish.org/2009/04/proposal-for-generalizing-byte-range.html 13:33:15 ohh 13:33:18 that's bad 13:33:24 two axis to identify a resource :) 13:33:41 URI request + media-fragment header 13:34:29 why do you need to send H1+K in the first request as you do a request to URL2 where you can send the whole thing? 13:35:33 because the answer of the second GET will be cached ? 13:35:41 what is the relationship between URL and URL2? 13:35:49 URL = URL 2 13:35:56 ... in most of the cases 13:35:56 90% yes ;) 13:35:59 ????? 13:37:49 Jack: is your URL/URL2 re-inventing the http-redirect? 13:38:04 I don't get why we need this complexity. at worst we need to locate a resolver and get the API to call it 13:38:51 I *think* the main purpose is to have the cacheability feature on the code data 13:39:05 ... but I think we have it with the current dual-step partial GET 13:40:40 Conrad: we need to do a bytes redirection for the second request 13:40:57 Raphael: in the spec, we have currently: X-Range-Redirect (new header) 13:41:56 ... Yves, how will you tell the user agent needs to issue another request to get the core of the video data ? do we need this new header ? 13:43:36 Michael: I would be very careful introducing complexity if the benefit is not totally clear and 'fool-proof'; lowers implementation barriers if we keep it simple 13:44:45 Jack: well, it is good in theory to call for a resolver (do the mapping between bytes and seconds) ... but in practice, this resolver will need to construct K (the key frames) 13:44:56 ... thus access the media, thus be on the server 13:46:55 Raphael: Yves, what is not clear in the current draft (among others :-), is the content of the body response of the first request in the dual step GET 13:47:27 ... should we have just the video data header (H') constructed on the server ? 13:47:35 I think that the clarification using letters is quite good and shoul make it to the 2nd publication :) 13:47:38 ... should we add also K (the key frames) 13:48:14 do you have the picture with the H, K? 13:51:30 Yves, http://www.w3.org/2008/WebVideo/Fragments/meetings/2009-04-16-f2f_barcelona/ogv_video_decomposition.jpg for the H, H', K, etc. 13:54:41 Yves: in the current draft, we haven't specify what is in the BODY of each response, right ? 13:54:52 no, but we should 13:55:18 Conrad mentions that in his solution: 1st response body contains the H' and K (new information/bytes constructed on the server) 13:55:36 ... while the 2nd response body contains only bytes coming from the original file 13:55:42 in the single GET solution the returned content should be H' K D2 13:55:48 ... and UA does the concatenation to get a complete playable resource 13:55:55 YES 13:56:10 in the case of the dual-step ? 13:56:10 and we shold craft that header to define where D2 is and its relation to the whole resource, as bytes 13:56:25 how ? 13:57:23 like Range-Mapping: bytes 1234-2345/58588; original=11234-12345/39849384 13:58:10 (or annodex might have a better format for that already :) ) 13:58:34 well, this is what Conrad proposes with its Range-Refer ... re his blog post :-) 13:58:40 no 13:58:48 he proposes a way to redirect without redirecting 13:59:01 I propose a mapping header for caches 13:59:22 he proposes to send the headers in the body of the first request, and the real video data in the body of the second request 13:59:45 on different URIs 13:59:51 I will bring your position in the room 14:00:05 ... no no no, assume now that URI = URI2 14:00:25 then it will confuse caches :) 14:00:44 basically if URL=URL2 the cache will flush what it cached at each request 14:01:17 well, the first response is not meant to be cached (just headers), the second one is a clear extract in terms of bytes of the resource and will be cached 14:01:35 the request is not the same 14:01:36 yeah, but a subsequent request on the same thing will invalidate what has just been cached 14:01:50 no, if this is not the same request ? 14:01:58 the second request is a normal Range request 14:01:59 -Yves 14:03:41 Zakim, who is on the phone? 14:03:41 On the phone I see Barcelona_Room 14:04:12 guillaume has joined #mediafrag 14:07:45 jackjansen: let's use an example video (from last F2F) and do practical experiments 14:08:18 ... and figure out how different formats (MPEG4, OGG) actually behave 14:10:51 Michael: I second jackjansen proposal 14:11:26 raphael: yes, let's do it and document in the Wiki 14:12:33 -Barcelona_Room 14:12:33 +Barcelona_Room 14:12:35 +Yves 14:12:40 Scribenick: guillaume 14:12:56 Topic: discoverability 14:13:11 Zakim, who is here? 14:13:11 On the phone I see Barcelona_Room, Yves 14:13:12 On IRC I see guillaume, conrad, FD, davy, dsinger, philipj, raphael, erik, Zakim, mhausenblas, jackjansen, RRSAgent, silvia, Yves, trackbot 14:14:01 Previously : Describe Conrad solution using the example (http implementation wiki page) to be enhanced with Conrad proposal 14:15:27 Conrad : what happen when we come across an URL like video.ogv#t=smpte-25=00'10.23.25,... 14:15:56 What would the code look like in the User Agent (the "smart" user agent) 14:17:59 It could be that the user agent split at the #, then after the request, start parsing what' s after the # (not good enough). It would have to check if it matches the syntax first. Reply comes back. 14:19:18 It' s the owner of the MIMIE type that understands what' s happening beyond the # (because so far, # "belongs / could be used" in any HTML document) 14:20:17 The server knows the MIME type, hence, the way to interpret the #etc... 14:24:08 ACTION mhausenblas Michael to write into the WD section 6.4, what the client should do with #everything after the hash : "Client Side Media Fragment Resolution" 14:24:08 Sorry, couldn't find user - mhausenblas 14:24:24 servers don't get the # part, it's supposed to be stripped by the UA, isn't it? 14:24:39 ACTION: Michael to write into the WD section 6.4, what the client should do with #everything after the hash : "Client Side Media Fragment Resolution" 14:24:39 Created ACTION-64 - Write into the WD section 6.4, what the client should do with #everything after the hash : "Client Side Media Fragment Resolution" [on Michael Hausenblas - due 2009-04-23]. 14:25:20 Coffee break time! 14:25:23 zakim, who is here? 14:25:23 On the phone I see Barcelona_Room, Yves 14:25:24 On IRC I see guillaume, conrad, FD, davy, dsinger, philipj, raphael, erik, Zakim, mhausenblas, jackjansen, RRSAgent, silvia, Yves, trackbot 14:25:24 coffeeeeeeeeeee 14:25:33 -Barcelona_Room 14:25:52 -Yves 14:25:53 IA_MFWG()3:00AM has ended 14:25:53 Attendees were Barcelona_Room, Yves 14:29:55 oh 14:30:02 I will probably be asleep when you get back 14:30:17 looks like there is progress :) 14:44:08 raphael: we will do now the joint meeting with the Annotation WG 14:44:21 Resuming 14:44:31 Zakim? 14:44:53 Use cases + requirements could make 1 separate document 14:45:03 IA_MFWG()3:00AM has now started 14:45:06 +Yves 14:45:06 the specification of the syntax would be the core document 14:45:14 +Mediafrag 14:45:50 Yeah, the teleconf is working 14:45:52 zakim, who is here? 14:45:53 On the phone I see Yves, Mediafrag 14:45:57 On IRC I see guillaume, conrad, FD, davy, dsinger, philipj, raphael, erik, Zakim, mhausenblas, jackjansen, RRSAgent, silvia, Yves, trackbot 14:46:05 Michael: we should only go with the Syntax REC-Track 14:46:19 We are going to have the joint meeting with the Media Annotation WG 14:46:34 ... the Test Cases (TC) and the Implementation Report (IR) should be a Note only 14:46:47 Topic: Numbers of documents 14:47:04 1. Use cases & Reqs 14:47:10 2. Synthax 14:47:29 raphael: current UC and Req will be split into UCR and Syntax doc 14:48:11 Action raphael Current UC and Req will be split into UCR and Syntax doc 14:48:11 Sorry, couldn't find user - raphael 14:48:29 trackbot, status 14:48:42 Action Raphaël Current UC and Req will be split into UCR and Syntax doc 14:48:42 Created ACTION-65 - Current UC and Req will be split into UCR and Syntax doc [on Raphaël Troncy - due 2009-04-23]. 14:49:25 3. Potentialy a 3rd document with Test cases 14:49:30 rrsagent, draft minutes 14:49:30 I have made the request to generate http://www.w3.org/2009/04/16-mediafrag-minutes.html mhausenblas 14:50:09 University people would like to make publications out of the work we produce here at the MFWG. 14:50:37 We would then add all our names to the joint co-authored paper(s) 14:50:38 +1 14:50:50 +1 14:51:39 +1 14:51:46 -Yves 14:52:07 IA_MFWG()3:00AM has ended 14:52:07 Attendees were Yves, Mediafrag 14:53:36 +1 (papers are always good ) 14:53:41 ;) 14:56:44 jackjansen has joined #mediafrag 15:09:19 wonsuk has joined #mediafrag 15:13:02 guillaume has joined #mediafrag 15:21:43 ACTION: Jack to look at the organisation of the 4th F2F meeting in Amsterdam on September 17-18 (just after IBC) 15:21:43 Created ACTION-66 - Look at the organisation of the 4th F2F meeting in Amsterdam on September 17-18 (just after IBC) [on Jack Jansen - due 2009-04-23]. 15:36:49 ACTION: Erik to sync with Jean Pierre to get the edit units spec reference 15:36:49 Created ACTION-67 - Sync with Jean Pierre to get the edit units spec reference [on Erik Mannens - due 2009-04-23]. 15:48:34 nessy has joined #mediafrag 15:48:54 I have made the request to generate http://www.w3.org/2009/04/16-mediafrag-minutes.html raphael 16:18:09 ACTION: Raphael to ask the Media Annotations WG to review our document 16:18:09 Sorry, couldn't find user - Raphael 16:18:16 trackbot, status? 16:18:41 ACTION: Raphaël to ask the Media Annotations WG to review our document 16:18:41 Created ACTION-68 - Ask the Media Annotations WG to review our document [on Raphaël Troncy - due 2009-04-23]. 16:19:02 I have made the request to generate http://www.w3.org/2009/04/16-mediafrag-minutes.html raphael 16:39:05 dsinger has joined #mediafrag 16:56:23 Zakim has left #mediafrag 16:58:16 davy has joined #mediafrag