IRC log of mediafrag on 2010-06-15

Timestamps are in UTC.

06:59:42 [RRSAgent]
RRSAgent has joined #mediafrag
06:59:42 [RRSAgent]
logging to
06:59:44 [trackbot]
RRSAgent, make logs public
06:59:44 [Zakim]
Zakim has joined #mediafrag
06:59:46 [trackbot]
Zakim, this will be IA_MFWG
06:59:46 [Zakim]
ok, trackbot; I see IA_MFWG()3:00AM scheduled to start in 1 minute
06:59:47 [trackbot]
Meeting: Media Fragments Working Group Teleconference
06:59:47 [trackbot]
Date: 15 June 2010
06:59:57 [RRSAgent]
I have made the request to generate raphael
07:00:12 [raphael]
Chair: Raphael, Erik
07:00:21 [raphael]
Regrets: Michael
07:00:41 [raphael]
07:38:29 [Zakim]
IA_MFWG()3:00AM has now started
07:38:37 [Zakim]
+ +
07:38:48 [raphael]
zakim, aaaa is Meeting_Room
07:38:48 [Zakim]
+Meeting_Room; got it
07:39:13 [FD]
FD has joined #mediafrag
07:39:31 [raphael]
Present: Jakub, Jack, Yves, Raphael, Erik, Davy, Wim, Franck, Silvia (remote)
07:39:51 [raphael]
Topic: 1. Administrative
07:41:13 [Zakim]
07:41:14 [Zakim]
IA_MFWG()3:00AM has ended
07:41:15 [Zakim]
Attendees were +, Meeting_Room
07:41:22 [Zakim]
IA_MFWG()3:00AM has now started
07:41:30 [Zakim]
+ +61.2.801.2.aaaa
07:41:41 [silvia]
zakim, aaaa is me
07:41:41 [Zakim]
+silvia; got it
07:42:10 [Zakim]
07:42:11 [Zakim]
IA_MFWG()3:00AM has ended
07:42:13 [Zakim]
Attendees were +61.2.801.2.aaaa, silvia
07:42:14 [Zakim]
IA_MFWG()3:00AM has now started
07:42:18 [Zakim]
07:44:47 [hackerjack]
hackerjack has joined #mediafrag
07:45:07 [raphael]
scribe: raphael
07:45:10 [Zakim]
07:45:10 [raphael]
scribenick: raphael
07:45:20 [dvdeurse]
dvdeurse has joined #mediafrag
07:45:26 [hackerjack]
zakim, Jack is me
07:45:26 [Zakim]
sorry, hackerjack, I do not recognize a party named 'Jack'
07:45:30 [dvdeurse]
dvdeurse has left #mediafrag
07:45:41 [hackerjack]
zakim, hackerjack is Jack
07:45:41 [Zakim]
sorry, hackerjack, I do not recognize a party named 'hackerjack'
07:45:50 [hackerjack]
zakim, Jack is hackerjack
07:45:50 [Zakim]
sorry, hackerjack, I do not recognize a party named 'Jack'
07:45:55 [Wim]
Wim has joined #mediafrag
07:46:01 [davy]
davy has joined #mediafrag
07:46:14 [raphael]
The agenda is at
07:46:44 [raphael]
... agenda approved
07:47:38 [raphael]
Topic: 2. Firefox plugin demo
07:52:50 [raphael]
Plugin and demos are available in the CVS repository
07:53:48 [raphael]
Jakub is presenting what the plugin can do
07:54:07 [raphael]
... do temporal and spatial fragments
07:54:32 [raphael]
... compliant with the current spec, generate the good headers and interact with the client mediua player
07:54:36 [raphael]
07:54:58 [raphael]
... use of custom controls for the media player in the UA from Davy
07:55:08 [raphael]
... connect to the ninsuna proxy server
07:56:08 [raphael]
Jakub showinf HTTP traces
07:56:35 [raphael]
07:56:52 [raphael]
Jakub: first demo,
07:57:34 [raphael]
... if you click elsewhere on the timeline, nothing happened ... we should fix this in the future
07:57:47 [raphael]
Jakub: second demo,
07:58:27 [raphael]
... what you get is the closest interval
07:58:50 [raphael]
Jack: let's keep this in mind, since I think we should have the smallest interval, not necesarily the closest
07:59:02 [raphael]
... let's keep this open and decide later on, since we might need more test cases
07:59:51 [raphael]
Jakub: third demo:
08:00:08 [raphael]
... just an overlay on the UA player ... no request sent to the server
08:01:19 [raphael]
... problem here: the server does not send X-Content-Duration header so no length written in the firefox timeline
08:02:39 [raphael]
Jakub: fourth demo: not yet there, a combination of temporal and spatial which nicely highlights the blackboard
08:05:50 [raphael]
Jakub is using Fiddler,
08:06:08 [raphael]
... but only on Windows
08:06:17 [raphael]
... you can use any HTTP proxy
08:06:36 [raphael]
... slightly more reliable than a firebug which is a firefox extension
08:08:09 [silvia]
good stuff!
08:08:12 [raphael]
Jakub: now showing the plugin options
08:08:25 [raphael]
... you will see the settings, where you can put a proxy address
08:08:32 [raphael]
... by default: Ninsuna
08:08:52 [raphael]
... so it can works for any video (e.g. YouTube) since they are proxying to Ninsuna
08:09:28 [silvia]
zakim, mute me
08:09:28 [Zakim]
silvia should now be muted
08:09:42 [raphael]
... Ninsuna can process on the fly any videos encoded in MP4
08:09:47 [raphael]
... ogg will follow soon
08:09:57 [raphael]
Jack: some questions regarding how the plugin works
08:10:04 [erik]
erik has joined #mediafrag
08:11:07 [raphael]
Jakub: the plugin uses the Firefox javascript API ... nothing standardized for setting up the headers
08:11:27 [erik]
rrsagent, draft minutes
08:11:27 [RRSAgent]
I have made the request to generate erik
08:11:46 [Yves]
08:12:04 [Yves]
rrsagent, draft minutes
08:12:04 [RRSAgent]
I have made the request to generate Yves
08:12:46 [raphael]
Raphael: who should detect stupid request? e.g. #t=30,20
08:12:56 [raphael]
... currently, the plugin is sending a request
08:15:30 [raphael]
Silvia: I think the plugin / browser should detect such mal-formed requests
08:16:01 [raphael]
Raphael: Yes Silvia, as it is written in, TC03
08:20:36 [raphael]
Jakub showing a very interesting example ... from the Mozilla web site, a video of Firefox 3.6
08:20:55 [raphael]
... where at one point, we get a 416 answer instead of a 200!
08:21:09 [raphael]
Yves pretends that Apache is wrong in this case
08:21:20 [silvia]
what is the request?
08:22:06 [Yves]
EACCcc server seems to be misbehaving
08:22:24 [Yves]
s/that Apache/that the server/
08:22:59 [jsendor]
jsendor has joined #mediafrag
08:23:12 [jsendor]
08:25:43 [hackerjack]
Jakub, use this URL for the non-mf-aware webserver example:
08:25:46 [raphael]
Yves: the issue is that when Jakub is sending a valid range but unknown by the server, the server is sending back a 416 instead of a 200
08:25:48 [jsendor]
I am sending exactly something like this:,0:00:20 + proper headers
08:25:52 [raphael]
... this is not the problem of Apache
08:25:57 [raphael]
... but a problem of this server
08:27:51 [erik]
scribe: Raphael
08:28:06 [erik]
ScribeNick: Raphael
08:28:16 [erik]
chair: Raphael, Erik
08:28:28 [erik]
08:28:41 [erik]
present: Jacob, Jack, Yves, Raphael, Erik, davy, Wim, Franck, Silvia
08:28:51 [erik]
regrets: Michael
08:29:01 [erik]
Date: 15 June 2010
08:29:12 [erik]
rrsagent, draft minutes
08:29:12 [RRSAgent]
I have made the request to generate erik
08:30:10 [raphael]
Raphael: which recipes are implemented ?
08:30:17 [raphael]
Jakub: the one with ;include-setup
08:30:28 [raphael]
... I'm not playing with the cache currently
08:30:43 [raphael]
Jack: if you click on the seeking bar, nothing is happening, right?
08:30:46 [raphael]
Jakub: yes
08:31:56 [raphael]
Raphael: limitation of the plugin = works in firefox, thus with theora codec (no h.264) ... will talk about the Chrome plugin later
08:33:04 [raphael]
Jack: precision, if you click on the seeking bar outside of the range the browsers knows about
08:34:09 [raphael]
Raphael: So only the recipe at 5.2.2 is implemented
08:34:23 [raphael]
... Actually:
08:34:56 [raphael]
Jakub: I try to investigate how to do a Chome plugin
08:35:06 [raphael]
... it is much newer, so currently we can do less things
08:35:27 [raphael]
... many requests from developers and Chrome is giving more and more power to developers but currently buggy
08:36:02 [raphael]
... might be difficult to have custom controls too on Chrome
08:36:09 [raphael]
... so rendering in UA will be difficult
08:37:51 [raphael]
Davy: Chrome has already implemented some smart media retrieval
08:38:17 [Zakim]
08:38:56 [raphael]
... live demo: open on Chrome
08:39:27 [raphael]
... even though the range is at the end, it plays immediately !
08:41:10 [raphael]
... chrome behaves differently with ogg, but just for MP4!
08:41:26 [raphael]
... the ability to jump immediately to a timepoint
08:42:25 [raphael]
Raphael: last issue, our demo is a HTML page that contains one video, is it or use case?
08:42:34 [raphael]
... what's happening if multiple videos on the page?
08:42:52 [raphael]
... what's happening if the URI is not an html document but a ogg resource?
08:43:53 [raphael]
Jakub: the fragments is applied to ALL <video> elements of the html page
08:44:25 [raphael]
... for the plugin, it does not know if the video resource has been directly requested or through a page
08:44:28 [silvia]
shouldn't the URI in the video element contain the fragment rather than the html page?
08:44:30 [raphael]
... it just adds headers
08:46:38 [raphael]
Jakub: the browser is requesting all elements contained in a page
08:47:28 [silvia]
each resource separately, as it should
08:47:56 [raphael]
Raphael: I agree
08:48:19 [raphael]
... what's happening when the URI in the browser bar is a media resource
08:48:37 [raphael]
Jakub: Firefox treats this separately, it is not a page
08:49:15 [raphael]
... headers are modified, so it works
08:49:34 [raphael]
... but we cannot have custom controls, so the UA cannot really render the fragment
08:50:17 [silvia]
you mean: the plugin cannot render the fragment?
08:50:31 [raphael]
Raphael: it can ... with some tricks
08:50:39 [raphael]
... removing the default controls of firefox
08:50:51 [raphael]
... and use the contextual menu to enforce custom controls
08:51:24 [raphael]
... the issue Silvia is that Firefox does not consider as a page
08:51:40 [raphael]
... you need to hide the default controls and enforce yours
08:52:17 [silvia]
yes, I understood that - I was wondering how you managed to get around it
08:52:35 [raphael]
Room applauses Jakub
08:54:53 [silvia]
I applaud Jakub, too :)
09:04:38 [tmichel]
tmichel has joined #mediafrag
09:16:51 [RRSAgent]
I have made the request to generate raphael
09:18:04 [raphael]
Topic: 3. Media Fragments URI syntax
09:18:11 [raphael]
09:18:11 [trackbot]
ACTION-152 -- Yves Lafon to change the formal syntax to reflect that we don't need a subdelim for selecting multiple tracks but we allow multiple track= in the URI + change the top level part to reflect the latest change on the mediasegment production -- due 2010-03-16 -- OPEN
09:18:11 [trackbot]
09:19:57 [raphael]
When the action has been given:
09:20:05 [Yves]
09:21:55 [raphael]
Yves: OK, I need to modify the grammar
09:22:13 [raphael]
Raphael: the semantics is a and, right?
09:22:41 [FD]
FD has joined #mediafrag
09:23:37 [raphael]
Jack: we need to look at the prose to make sure that because of this, the media can get 'bigger', since we are collecting potentially many tracks
09:27:41 [raphael]
Raphael: I have an announcement
09:27:53 [raphael]
09:27:53 [trackbot]
ACTION-119 -- Yves Lafon to request admins to set up a cvs notifications mailing list and notifications -- due 2009-10-14 -- OPEN
09:27:53 [trackbot]
09:27:58 [raphael]
The mailing list has been setup
09:28:16 [raphael]
It is:
09:28:30 [raphael]
... you must subscribe to it if you wish to get notifications in our repository
09:28:43 [Yves]
09:28:55 [raphael]
... for example, get notifications for all the demo files uploaded this morning
09:29:03 [raphael]
... but also chaanges in the spec
09:29:24 [raphael]
... this is an opt-in mailing list, so far, only Yves and I are subscribed
09:29:34 [raphael]
close ACTION-119
09:29:34 [trackbot]
ACTION-119 Request admins to set up a cvs notifications mailing list and notifications closed
09:30:15 [raphael]
Raphael: Yves is working now on the ACTION-152
09:34:06 [raphael]
... formal grammar fixed now for the URI syntax
09:34:16 [raphael]
... allow multiple 'track=' in the URI
09:34:29 [raphael]
... nothing to change in the header syntax since Silvia has already foreseen the case
09:34:44 [raphael]
... i.e: track-ranges-specifier = trackprefix "=" trackparam *( ";" trackparam )
09:40:38 [raphael]
close ACTION-152
09:40:39 [trackbot]
ACTION-152 Change the formal syntax to reflect that we don't need a subdelim for selecting multiple tracks but we allow multiple track= in the URI + change the top level part to reflect the latest change on the mediasegment production closed
09:40:55 [raphael]
09:40:55 [trackbot]
ACTION-160 -- Yves Lafon to send an email reporting the issue for track names -- due 2010-04-14 -- OPEN
09:40:55 [trackbot]
09:41:27 [raphael]
Yves: mail has not been sent
09:41:32 [raphael]
... I will explain the issue
09:41:59 [raphael]
we are seeing more and more IRIs, so what should be the encoding of a fragment in a IRI?
09:42:58 [raphael]
... how do we specify that track names should be encoded in UTF-8 if the IRIs is encoded differently ?
09:44:09 [raphael]
Yves: there are mappings between IRIs and URIs
09:44:59 [raphael]
... IRIs can be a different character set
09:45:11 [Yves]
09:47:40 [raphael]
Jack is giving an example mixing latin2 (Polish with /L), utf8 and Big5 (Chinese) encoding
09:48:10 [raphael]
Jack: I think it is not a unique problem for us
09:48:13 [raphael]
... I'm pretty sure actually
09:48:22 [raphael]
... so other groups must have faced this issue
09:49:22 [raphael]
Raphael: suggest that Yves's action is transformed into a mail to the Internationalization WG cc-ing us to flag the issue we have
09:51:21 [Yves]
09:53:17 [raphael]
... suggest that Yves does this action after lunch break
09:53:27 [raphael]
09:53:27 [trackbot]
ACTION-170 -- Yves Lafon to send an email about metadata headers and 206 responses -- due 2010-06-09 -- OPEN
09:53:27 [trackbot]
09:54:12 [raphael]
See Yves's email at
09:55:42 [raphael]
See Silvia's understanding of the issue:
09:57:32 [raphael]
Yves: first issue, if you have the header data of the media file, and try to get now a fragment of it, you need to make sure the representation of the resouce has not changed
09:57:47 [raphael]
... works with if-range and etag
09:58:28 [Yves]
10:00:19 [raphael]
Yves: second issue, drawing on the blackboard
10:01:26 [raphael]
... request a first fragment (request 1) triggers a reply with a Content-Range-Mapping header
10:01:58 [raphael]
... request a second fragment (request 2) triggers another reply with another Content-Range-Mapping header
10:02:46 [raphael]
... the Content-Range-Mapping is an Entity Header ... so it will be saved
10:03:50 [raphael]
... that's why I think we should NOT add any new headers in the spec
10:15:58 [raphael]
Yves: summary, IF-RANGE is an orthogonal issue ... it is just to ensure that we have a fresh copy
10:19:53 [raphael]
... headers apply to the full resource
10:29:57 [raphael]
Jack: I understand the issue ... but we need paragraphs in the spec
10:30:20 [raphael]
... perhaps a new section of how caches must work, sililar to section 7 for clients
10:30:27 [raphael]
10:31:55 [raphael]
... drawing will put in the wiki in lunch
11:03:05 [tmichel]
tmichel has joined #mediafrag
11:15:55 [silvia]
silvia has joined #mediafrag
11:19:21 [conrad]
conrad has joined #mediafrag
11:34:22 [raphael]
Raphael: after lunch break, continuing on ACTION-170
11:35:21 [raphael]
... now, we have a drawing on the wiki
11:35:29 [raphael]
... see
11:36:21 [raphael]
Raphael: I think the discussion should now interest both Silvia and Conrad ... we are discussing a proper use of the Content-Range-Mapping header
11:36:59 [conrad]
Zakim, code?
11:36:59 [Zakim]
the conference code is 3724 (tel:+1.617.761.6200 tel:+ tel:+44.117.370.6152), conrad
11:37:24 [raphael]
11:38:04 [Zakim]
11:38:48 [raphael]
11:38:49 [trackbot]
ACTION-170 -- Yves Lafon to send an email about metadata headers and 206 responses -- due 2010-06-09 -- OPEN
11:38:49 [trackbot]
11:39:31 [Zakim]
11:39:39 [conrad]
Zakim, ??P8 is me
11:39:39 [Zakim]
+conrad; got it
11:39:44 [RRSAgent]
I have made the request to generate raphael
11:42:24 [conrad]
Zakim, mute me
11:42:24 [Zakim]
conrad should now be muted
11:43:00 [conrad]
Zakim, unmute me
11:43:00 [Zakim]
conrad should no longer be muted
11:48:22 [raphael]
Jack: further explanation ... in the 3rd solution of the picture, the CR has just bytes ... while the CRM has both bytes + seconds
11:51:03 [raphael]
Conrad: your problem is you have just one request header (Range) and several reply headers (for handling caching)
11:52:15 [raphael]
Yves: if you have a Vary header, the cache will not cache anything at all
11:54:01 [conrad]
Zakim, mute me
11:54:01 [Zakim]
conrad should now be muted
11:55:46 [Yves]
Req1: Get time range 0-5, reply bytes 0-2048 + crm 0-5, a nmf-aware cache will cache this
11:56:25 [Yves]
req2: Get time range 5-10, reply byte 2048-4096 + crm 5-10. a nmf-aware cache will cache it and update crm to be 5-10 only
11:56:44 [Yves]
req3: get byte range 0-4096, cache will reply with bytes 0-4096 with crm 5-10
11:57:01 [Yves]
so the client will think that 5-10s == 0-4096 bytes which is wrong
11:57:07 [raphael]
Jack: the CRM header is a solution for optimizing the case where old caches will be able to cache media fragments expressed in seconds, but will be able to serve it only when a subsequent request is expressed in terms of byte ranges
11:57:17 [Yves]
hance the need to put in CRM 2048-4096 = 5s-10s
11:57:19 [conrad]
so a UA or cache that understands time ranges must be able to understand byte ranges, and can effectively ignore the c-r-m response header and just deal with byte ranges?
11:57:24 [raphael]
... is it not a corner case?
11:57:58 [silvia]
conrad: yes, that's the idea
11:57:59 [Yves]
an UA that understands time ranges can do what it wants
11:58:11 [Yves]
an UA knowing only byte ranges won't give misleading information
11:58:19 [Yves]
that's the only point
11:58:32 [conrad]
well, a ua that only understands byte ranges isn't going to make the time range request in the first place
11:58:46 [Yves]
Adding a Vary: Range, on each request, the cnon-mf aware cache will clear its current entry
11:58:56 [conrad]
Yves, I don't understand what you mean by "can do what it wants"
11:59:09 [conrad]
obviously the only thing to do is to accept the body and play it
11:59:50 [conrad]
yes, i wouldn't vary on range on this response
12:00:04 [conrad]
yes, i wouldn't vary on range on this request
12:00:29 [conrad]
Zakim, unmute me
12:00:29 [Zakim]
conrad should no longer be muted
12:00:39 [Yves]
A mf-aware UA may ignore the byte range, and take only the range in second form the CRM, (but receiving a 206 means that the server understood and sent the right fragment)
12:02:49 [tmichel]
tmichel has joined #mediafrag
12:03:58 [raphael]
Yves: if a client has sent time range request, and receives a 200 with a CRM because the cache does not understand Media Fragments, then the client should not cache the CRM that does not belong to the 200 respnse
12:04:05 [raphael]
12:05:19 [silvia]
12:05:49 [raphael]
Raphael: we are discussing now recipes described in and
12:06:55 [raphael]
... headlines are wrong, since all 5.2.2.x solutions are cacheable in some sense
12:08:09 [raphael]
Davy: CRM is useless in the case of a 200 response
12:08:26 [raphael]
... or if the UA makes a byte ranges request
12:08:51 [raphael]
Raphael: we need to add a paragraph for explaining this clearly in the spec
12:08:59 [raphael]
... the rationale for the introduction of this new header
12:10:01 [silvia]
Next to the introduction of new dimensions for the HTTP Range request header, we also introduce a new HTTP response header, called Content-Range-Mapping, which provides the mapping of the retrieved byte range to the original Range request, which was not in bytes. It serves two purposes:
12:10:01 [silvia]
•It Indicates the actual mapped range in terms of fragment dimensions. This is necessary since the server might not be able to provide a byte range mapping that corresponds exactly to the requested range. Therefore, the User Agent needs to be aware of this variance.
12:10:01 [silvia]
It provides context information regarding the parent resource in case the Range request contained a temporal dimension. More specifically, the header contains the start and end time of the parent resource. This way, the User Agent is able to understand and visualize the temporal context of the media fragment.
12:10:18 [conrad]
Zakim, mute me
12:10:18 [Zakim]
conrad should now be muted
12:10:58 [raphael]
RESOLUTION: adopt the third solution drawn on the wiki
12:11:09 [raphael]
ACTION: Yves to modify the ABNF syntax of the Content-Range-Mapping header to take into account this resolution
12:11:09 [trackbot]
Created ACTION-171 - Modify the ABNF syntax of the Content-Range-Mapping header to take into account this resolution [on Yves Lafon - due 2010-06-22].
12:12:14 [raphael]
Silvia: I support very much a section for caches
12:13:35 [raphael]
Jack: I would suggest we rename the section 7 into a "Note for Implementers"
12:13:48 [raphael]
... with 7.1: For UA implementers ... how to render Media Fragments
12:14:04 [raphael]
... with 7.2: For cache implementers ... how to handle Media Fragments
12:14:26 [conrad]
how about for each example, you show how you would retrieve the first 10k of a media fragment request, ie. the first 10k of "this video from time 5-10min" ... then the next 10k ... then the next 10k ... of that
12:14:38 [conrad]
if you can do that, it's probably usefully cacheable, and streamable
12:15:38 [raphael]
ACTION: Jack to work on the existing Section 7, and draft 7.2
12:15:38 [trackbot]
Created ACTION-172 - Work on the existing Section 7, and draft 7.2 [on Jack Jansen - due 2010-06-22].
12:17:25 [raphael]
close ACTION-170
12:17:25 [trackbot]
ACTION-170 Send an email about metadata headers and 206 responses closed
12:21:59 [FD]
FD has joined #mediafrag
12:22:17 [conrad]
Zakim, unmute me
12:22:17 [Zakim]
conrad should no longer be muted
12:22:18 [raphael]
Jack: to conrad, bytes range are absolute with respect to the original resource, so no cascading
12:23:31 [raphael]
Topic: 4. Protocol Handling
12:23:50 [conrad]
Zakim, mute me
12:23:50 [Zakim]
conrad should now be muted
12:26:40 [silvia]
zakim, mute me
12:26:40 [Zakim]
silvia should now be muted
12:29:15 [raphael]
Wim: issue for non multiplexed file ... the video is in the beginning and the audio starts in the middle
12:29:24 [raphael]
... the time ranges correspond to multiple byte ranges
12:29:41 [raphael]
... how this should be represented in the CRM header?
12:33:12 [raphael]
Erik: Wim, can you write an example on IRC?
12:34:04 [silvia]
Wim: is your answer
12:34:45 [Zakim]
12:34:57 [Wim]
Content-Range-Mapping: t:npt 10-20;include-setup=bytes 0-2000,4000-10000/20000
12:35:53 [silvia]
ah, yes, that needs to be included in CRM with multiple byte ranges - that's correct IMHO
12:35:58 [Wim]
Content-Range-Mapping: t:npt 10-20/0-38;include-setup=bytes 0-2000,4000-10000/20000
12:36:20 [silvia]
no, you cannot ask for multiple time ranges
12:36:41 [davy]
0-38 is the total duration
12:36:46 [silvia]
ah,ok, fine
12:36:55 [silvia]
how about this:
12:37:03 [silvia]
Content-Range-Mapping: t:npt 10-20/0-38;include-setup eq bytes 0-2000,4000-10000/20000
12:37:23 [silvia]
a keyword "eq" in the middle with spaces around
12:37:45 [silvia]
zakim, unmute me
12:37:45 [Zakim]
silvia should no longer be muted
12:37:52 [conrad]
in, can you receive multiple byte-ranges in the Range-Redirect response header?
12:38:06 [conrad]
ah yes you can :)
12:38:26 [conrad]
(the example only had one)
12:39:20 [FD]
Assuming bytes 0-2000 correspond to include-setup, I would prefer: Content-Range-Mapping: t:npt 10-20/0-38;include-setup eq bytes 4000-10000,0-2000/20000
12:39:30 [silvia]
Content-Range-Mapping: (t:npt 10-20/0-38;include-setup)  eq  (bytes 0-2000,4000-10000/20000) ?
12:40:21 [Yves]
let's use <...>
12:40:37 [raphael]
Raphael: then replace 'eq' by 'equal'?
12:40:43 [silvia]
Content-Range-Mapping: <t:npt 10-20/0-38;include-setup>  eq  <bytes 0-2000,4000-10000/20000>
12:40:59 [silvia]
Yves: it looks a bit ugly, to be honest...
12:41:09 [raphael]
Raphael: no need for parenthesis
12:41:50 [Yves]
CRM: t:npt 10-20/0-38;include-setup = bytes 0-2000,4000-1000/2000
12:41:55 [silvia]
Content-Range-Mapping: t:npt 10-20/0-38;include-setup  equals  bytes 0-2000,4000-10000/20000
12:42:00 [Yves]
a=b is usually readable
12:42:58 [silvia]
CRM: (t:npt 10-20/0-38;include-setup) = (bytes 0-2000,4000-1000/2000)
12:42:59 [Yves]
and more efficient
12:43:11 [raphael]
Wim: '=' is better to parse
12:43:29 [Yves]
only one = is allowed => no need for parenthesis
12:43:57 [Yves]
remember that it has to be parsed by machines
12:44:00 [raphael]
We need a primary separator (e.g. =) and a secondary one (the ';')
12:44:06 [Yves]
(and debugged only by knowledgeable humans :) )
12:44:08 [hackerjack]
Would this work? CRM: t:npt 10-20/0-38;include-setup bytes 0-2000,4000-1000/2000
12:44:32 [silvia]
please let's have a separator or some sort
12:44:39 [silvia]
zakim, mute me
12:44:39 [Zakim]
silvia should now be muted
12:45:07 [hackerjack]
ok, you've convinced me:-)
12:45:15 [raphael]
First option: Content-Range-Mapping: t:npt 10-20;include-setup=bytes 0-2000,4000-10000/20000
12:45:31 [silvia]
12:45:56 [silvia]
zakim, unmute me
12:45:56 [Zakim]
silvia should no longer be muted
12:46:30 [Yves]
why not removing ';'
12:46:45 [Yves]
Content-Range-Mapping: t:npt 10-20 include-setup=bytes 0-2000,4000-10000/20000
12:47:13 [FD]
Content-Range-Mapping: t:npt 10-20,include-setup=bytes 0-2000,4000-10000/20000
12:47:51 [raphael]
Jack: CRM: (t:npt 10-20/0-38;include-setup) (bytes 0-2000,4000-1000/2000)
12:48:07 [Yves]
{} instead?
12:48:13 [davy]
Content-Range-Mapping: t:npt 10-20 include-setup>bytes 0-2000,4000-10000/20000 ?
12:48:14 [silvia]
if we remove ';' , we should just make it a series of statements:
12:48:23 [silvia]
Content-Range-Mapping: t:npt 10-20 include-setup bytes 0-2000,4000-10000/20000
12:48:41 [Yves]
silvia, yes hence the { token* }
12:48:52 [hackerjack]
§, anyone?
12:49:29 [raphael]
PROPOSES: CRM: {t:npt 10-20/0-38;include-setup} {bytes 0-2000,4000-1000/2000}
12:50:25 [Yves]
better with an = in the middle (clearer in the intend), but no big deal if it's not there
12:50:54 [raphael]
PROPOSED: CRM: {t:npt 10-20/0-38;include-setup}={bytes 0-2000,4000-1000/2000}
12:51:10 [davy]
12:51:13 [erik]
12:51:16 [Yves]
sounds good to me
12:51:16 [Wim]
12:51:20 [raphael]
12:51:20 [silvia]
Content-Range-Mapping: t:npt 10-20; include-setup; bytes 0-2000,4000-10000/20000
12:51:22 [hackerjack]
12:51:37 [silvia]
based on:
12:51:37 [silvia]
Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1
12:51:55 [silvia]
I checked how other headers work at
12:52:25 [silvia]
12:52:30 [silvia]
+1 on the above
12:53:06 [silvia]
it's the talkative header ;)
12:53:30 [raphael]
RESOLUTION: new syntax for the Content-Range-Mapping header, "Content-Range-Mapping: {t:npt 10-20/0-38;include-setup}={bytes 0-2000,4000-1000/2000}"
12:53:35 [RRSAgent]
I have made the request to generate raphael
12:54:30 [raphael]
12:54:30 [trackbot]
ACTION-166 -- Yves Lafon to review the ABNF syntax of the HTTP headers introduced by the Media Fragment URI spec -- due 2010-06-02 -- OPEN
12:54:30 [trackbot]
12:55:55 [raphael]
Yves: I will produce the code for checking the grammar of the ABNF syntax of the headers as for the URI syntax
12:56:16 [raphael]
close ACTION-166
12:56:16 [trackbot]
ACTION-166 Review the ABNF syntax of the HTTP headers introduced by the Media Fragment URI spec closed
12:56:44 [raphael]
ACTION: Yves to produce the code that will check the grammar of both the URI syntax and the Headers syntax
12:56:45 [trackbot]
Created ACTION-173 - Produce the code that will check the grammar of both the URI syntax and the Headers syntax [on Yves Lafon - due 2010-06-22].
12:57:56 [raphael]
Jack: there is common bits between the uri syntax and the header syntax
12:58:17 [raphael]
... could we split this into 3 blocks: common syntax, uri syntax and header syntax ?
12:58:20 [silvia]
zakim, mute me
12:58:20 [Zakim]
silvia should now be muted
12:59:20 [raphael]
ACTION: Yves to produce the common syntax block
12:59:20 [trackbot]
Created ACTION-174 - Produce the common syntax block [on Yves Lafon - due 2010-06-22].
12:59:22 [silvia]
we are also repeating some code from the HTTP spec
12:59:35 [silvia]
so it's 4 blocks really
13:00:15 [raphael]
Yves: we are importing some stuff as a convenience ... but the normative is in the HTTP spec referenced
13:00:43 [silvia]
except where we extend it ;)
13:00:43 [raphael]
13:00:43 [trackbot]
ACTION-137 -- Jack Jansen to check that section 5.2 is implementable using the protocol -- due 2010-02-10 -- OPEN
13:00:43 [trackbot]
13:08:01 [raphael]
We found back what was the action :-)
13:08:22 [raphael]
It is actually to read and review the _current_ section 5.1!
13:09:05 [raphael]
Jack: I will put this into the section 7!
13:09:32 [raphael]
... I think the section 7 will not be normative ... but this important stuff that needs to be said
13:11:53 [raphael]
Raphael: ACTION-137 is ongoing
13:12:03 [raphael]
... now rephrased into: Merge the content of section 5.1in the future section 7 (and check whether it is implementable using the protocol?)
13:13:40 [Yves]
3:13pm here
13:14:55 [raphael]
Jack: looking back at some past actions we should close
13:15:52 [raphael]
drop ACTION-34
13:16:52 [hackerjack]
trackbot, help
13:16:52 [trackbot]
See for help
13:16:59 [hackerjack]
13:17:30 [raphael]
close ACTION-34
13:17:30 [trackbot]
ACTION-34 Look at python-url library to see whether he could implement the logic on client side closed
13:18:23 [raphael]
comment ACTION-35 we might come back to these if we are lacking implementations, but no resources on this now
13:18:29 [raphael]
close ACTION-35
13:18:30 [trackbot]
ACTION-35 Look at curl and/or wget to see whether the logic could be implemented on client side closed
13:18:34 [RRSAgent]
I have made the request to generate raphael
13:20:30 [raphael]
Topic: 5. Other dimensions (track, id, xywh)
13:20:52 [raphael]
Jack: I would like to make a disctinction between the URI syntax part and the HTTP handling part
13:20:59 [raphael]
... the first being well thought, sort-of
13:21:08 [raphael]
... the second hasn't been enough discussed
13:23:09 [raphael]
Raphael: let's talk first about the xywh dimension
13:23:20 [raphael]
... we have implementation on client (Jakub) and server (Ninsuna)
13:23:23 [raphael]
... purely on client side
13:23:48 [davy]
s/and server (Ninsuna)/
13:23:59 [raphael]
... nothing transmitted over the wire
13:24:48 [silvia]
I prefer it to stay that way actually
13:25:01 [raphael]
Jack: xywh will only be standardized in URI and not in protocol
13:25:21 [raphael]
Raphael: yes silvia, question is whether we put strong statements or not in the spec
13:25:39 [silvia]
reason being that right now there are no codecs I believe where spatial cropping can be done by byte ranges
13:25:51 [silvia]
but we should add a note that it is possible to extend this in the future?
13:26:17 [Yves]
well there is no need to bind that to byte ranges
13:26:30 [Yves]
but not saying anything means that the door is not closed
13:26:50 [silvia]
13:27:06 [raphael]
OK, we have the text already written in the spec
13:27:11 [raphael]
... for the explanation
13:27:33 [raphael]
"Note that the specification does not foresee a Range dimension for spatial media fragments since they are typically resolved and interpreted by the User Agent (i.e., spatial fragment extraction is not performed on server-side) due to the following reasons: "
13:27:57 [raphael]
13:28:54 [raphael]
Jack: two use cases for this, the grey overlay and the sprite that CSS people want to do
13:29:09 [raphael]
Raphael: track dimension
13:30:41 [raphael]
... clear use cases in the accessibility community
13:31:48 [raphael]
Davy: implementation problem with tracks when we want to cache it ... too many characters to store!
13:36:24 [raphael]
Wim: we can always have the problem, a time range yields too many byte ranges! ... but it is rare for a time range, while it happens for a track range
13:38:29 [raphael]
Davy: how Ninsuna currently works, is via the '?' ... a redirect from a hash to the query
13:39:46 [raphael]
Jack: should we write this in our new section 7?
13:39:59 [RRSAgent]
I have made the request to generate raphael
13:43:14 [raphael]
Raphael: discussion how to handle track and id ... appealing solution from Jack
13:43:25 [hackerjack]
Silvia, you still here?
13:43:47 [raphael]
... do a redirect in the HTTP sense (30x)
13:44:08 [raphael]
... to a URI with a query
13:50:56 [silvia]
a redirect can always be performed - I think we should describe this generally
13:59:07 [Zakim]
13:59:35 [raphael]
Raphael: we are documenting the solution ... which in a nutshell comes back to always do a redirection when there is track or id selection
14:00:01 [raphael]
... solution is cacheable but not 'mergeable'
14:00:58 [silvia]
14:01:08 [silvia]
you can always combine a query with a fragment request
14:01:25 [raphael]
yeah yeah, we are not talking about this
14:05:17 [tmichel]
tmichel has joined #mediafrag
14:14:44 [raphael]
Topic: 6. Handling track and id
14:15:14 [raphael]
Raphael: I'm giving a try to describe what is the envisionned solution for parsing Media Fragment URI that contains a track or an id selection
14:16:19 [raphael]
... Case 1: URI requested is under the form: or
14:16:37 [raphael]
... The UA sends a Range request to the server
14:17:07 [raphael]
... this request has a Range header, "Range: track=myaudio"
14:17:24 [raphael]
... the server sends a 30x reply indicating a Redirect
14:18:09 [raphael]
... this reply has a Location header, "Location:"
14:18:30 [raphael]
... (where the # has been transformed by a ? per server decision)
14:19:05 [raphael]
... the UA sends another request, a normal one this time:
14:20:12 [raphael]
... the server will serve a complete new resource (per the use of the query parameter) with a 200 reply
14:20:49 [raphael]
... in addition, we enforce that the second reply contains a Link header, pointing to the original resource, i.e.
14:21:16 [raphael]
... Case 2: Combination of track selection and time ranges
14:21:37 [raphael]
... URI requested under the form:,50
14:21:48 [raphael]
... The UA sends a Range request to the server
14:22:24 [raphael]
... this request has again a Range header, e.g., "Range: track=myaudio,t:npt=20-50"
14:22:45 [raphael]
the server sends a 30x reply indicating a Redirect because of the presence of the track selection
14:23:18 [raphael]
... this reply has a Location header that points to a Media Fragment URI, "Location:,50"
14:23:59 [raphael]
... the UA sends another request, a RANGE request because of the presence of the '#':,50
14:24:25 [raphael]
... the server will serve a Partial Content reply (206) of a newly constructed resource
14:25:44 [raphael]
... in addition, we enforce that the second replu contains a Link header, pointing to the original resource, i.e.
14:26:29 [raphael]
14:26:32 [raphael]
14:27:00 [raphael]
Raphael: In summary, we _always_ handle the track and id selections by a Redirection
14:27:40 [raphael]
... we keep the original author intention of using a hash by putting back a link to the original resource with the Link header
14:28:01 [raphael]
... this solution is cacheable by the current infrastructure
14:28:28 [raphael]
Raphael: This needs to be approved tomorrow
14:28:40 [raphael]
Topic: 7. Housekeeping
14:28:53 [raphael]
close ACTION-169
14:28:53 [trackbot]
ACTION-169 Reserve the bridge for 15&16 June mediafrag f2f closed
14:32:27 [RRSAgent]
I have made the request to generate raphael
14:43:05 [Yves]
just finishedchanges for Content-Range-Mapping, including examples
14:43:23 [Yves]
can someone check this? (especially examples, the 307 case of remapping being of interest)
15:22:17 [raphael]
ACTION: Yves to update the grammar parsing automatically generated code for the URI syntax
15:22:17 [trackbot]
Created ACTION-175 - Update the grammar parsing automatically generated code for the URI syntax [on Yves Lafon - due 2010-06-22].
15:22:34 [raphael]
15:22:34 [trackbot]
ACTION-70 -- Jack Jansen to commit in CVS (code directory) his python code doing the parsing on client side of the media fragment -- due 2009-10-14 -- OPEN
15:22:34 [trackbot]
15:28:16 [raphael]
close ACTION-137
15:28:16 [trackbot]
ACTION-137 Merge the content of section 5.1in the future section 7 (and check whether it is implementable using the protocol?) closed
15:29:28 [raphael]
close ACTION-172
15:29:28 [trackbot]
ACTION-172 Work on the existing Section 7, and draft 7.2 closed
15:29:35 [raphael]
ALL: we need to review the section 7
15:30:40 [raphael]
close ACTION-70
15:30:40 [trackbot]
ACTION-70 Commit in CVS (code directory) his python code doing the parsing on client side of the media fragment closed
15:31:13 [raphael]
close ACTION-160
15:31:13 [trackbot]
ACTION-160 Send an email to the Internationalization WG + us reporting the issue for track names closed
15:31:27 [raphael]
15:31:58 [raphael]
close ACTION-171
15:31:58 [trackbot]
ACTION-171 Modify the ABNF syntax of the Content-Range-Mapping header to take into account this resolution closed
15:33:15 [raphael]
Tomorrow: come back to the discussion on handling tracks and id
15:33:24 [raphael]
... go through all ISSUES
15:34:26 [raphael]
... + demo of test cases framework from Davy / Wim
15:34:30 [raphael]
[meeting adjourned]
15:34:37 [RRSAgent]
I have made the request to generate raphael
15:37:46 [Zakim]
15:37:47 [Zakim]
IA_MFWG()3:00AM has ended
15:37:48 [Zakim]
Attendees were silvia, Jakob, Jack, Yves, Raphal, Erik, Davy, ??, Frank, conrad
15:57:42 [Zakim]
Zakim has left #mediafrag