IRC log of mediafrag on 2009-04-16

Timestamps are in UTC.

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