Media Fragments Working Group Teleconference -- 15 Jun 2010

<trackbot> Date: 15 June 2010

1. Administrative

<scribe> scribe: raphael

<scribe> scribenick: raphael

The agenda is at http://www.w3.org/2008/WebVideo/Fragments/wiki/SixthF2FAgenda

scribe: agenda approved

2. Firefox plugin demo

Plugin and demos are available in the CVS repository

Jakub is presenting what the plugin can do

scribe: do temporal and spatial fragments
... compliant with the current spec, generate the good headers and interact with the client media player
... use of custom controls for the media player in the UA from Davy
... connect to the ninsuna proxy server

Jakub showing HTTP traces

Jakub: first demo, http://www.w3.org/2008/WebVideo/Fragments/code/plugin/demos/temporal/demo_10-20.html
... if you click elsewhere on the timeline, nothing happened ... we should fix this in the future
... second demo, http://www.w3.org/2008/WebVideo/Fragments/code/plugin/demos/temporal/demo_5-15.html
... what you get is the closest interval

Jack: let's keep this in mind, since I think we should have the smallest interval, not necesarily the closest
... let's keep this open and decide later on, since we might need more test cases

Jakub: third demo: http://www.w3.org/2008/WebVideo/Fragments/code/plugin/demos/spatial/demo_spatial1.html
... just an overlay on the UA player ... no request sent to the server
... problem here: the server does not send X-Content-Duration header so no length written in the firefox timeline
... fourth demo: not yet there, a combination of temporal and spatial which nicely highlights the blackboard

Jakub is using Fiddler, http://www.fiddler2.com/fiddler2/

scribe: but only on Windows
... you can use any HTTP proxy
... slightly more reliable than a firebug which is a firefox extension

<silvia> good stuff!

Jakub: now showing the plugin options
... you will see the settings, where you can put a proxy address
... by default: Ninsuna
... so it can works for any video (e.g. YouTube) since they are proxying to Ninsuna
... Ninsuna can process on the fly any videos encoded in MP4
... ogg will follow soon

Jack: some questions regarding how the plugin works

Jakub: the plugin uses the Firefox javascript API ... nothing standardized for setting up the headers

<Yves> s/?Wim/Wim/

Raphael: who should detect stupid request? e.g. #t=30,20
... currently, the plugin is sending a request

Silvia: I think the plugin / browser should detect such mal-formed requests

Raphael: Yes Silvia, as it is written in http://www.w3.org/2008/WebVideo/Fragments/wiki/TemporalDimension, TC03

Jakub showing a very interesting example ... from the Mozilla web site, a video of Firefox 3.6

scribe: where at one point, we get a 416 answer instead of a 200!

Yves pretends that the server is wrong in this case

<silvia> what is the request?

<Yves> EACCcc server seems to be misbehaving

<jsendor> http://videos-cdn.mozilla.net/firefox/3.6/whatsnewin36.ogv

<hackerjack> Jakub, use this URL for the non-mf-aware webserver example: http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.ogv

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

<jsendor> I am sending exactly something like this: http://html5demos.com/assets/dizzy.ogv#t=0:00:05,0:00:20 + proper headers

Yves: this is not the problem of Apache
... but a problem of this server

<erik> scribe: Raphael

<erik> ScribeNick: Raphael

<erik> chair: Raphael, Erik

<erik> agenda: http://www.w3.org/2008/WebVideo/Fragments/wiki/SixthF2FAgenda

<erik> Date: 15 June 2010

Raphael: which recipes are implemented ?

Jakub: the one with ;include-setup
... I'm not playing with the cache currently

Jack: if you click on the seeking bar, nothing is happening, right?

Jakub: yes

Raphael: limitation of the plugin = works in firefox, thus with theora codec (no h.264) ... will talk about the Chrome plugin later

Jack: precision, if you click on the seeking bar outside of the range the browsers knows about

Raphael: So only the recipe at 5.2.2 is implemented
... Actually: 5.2.2.2

Jakub: I try to investigate how to do a Chome plugin
... it is much newer, so currently we can do less things
... many requests from developers and Chrome is giving more and more power to developers but currently buggy
... might be difficult to have custom controls too on Chrome
... so rendering in UA will be difficult

Davy: Chrome has already implemented some smart media retrieval
... live demo: open http://ninsuna.elis.ugent.be/MediaFragmentsPlayerHTML?url=http%3A//ninsuna.elis.ugent.be/DownloadServlet/apple/10%2C000_BC_trailer_2.mp4%3Ftrack%3D1%3B2%23t%3D100%2C110%26xywh%3Dpercent%3A10%2C10%2C50%2C50&ajax=1&height=375&width=1180 on Chrome
... even though the range is at the end, it plays immediately !
... chrome behaves differently with ogg, but just for MP4!
... the ability to jump immediately to a timepoint

Raphael: last issue, our demo is a HTML page that contains one video, is it or use case?
... what's happening if multiple videos on the page?
... what's happening if the URI is not an html document but a ogg resource?

Jakub: the fragments is applied to ALL <video> elements of the html page
... for the plugin, it does not know if the video resource has been directly requested or through a page

<silvia> shouldn't the URI in the video element contain the fragment rather than the html page?

Jakub: it just adds headers
... the browser is requesting all elements contained in a page

<silvia> each resource separately, as it should

Raphael: I agree
... what's happening when the URI in the browser bar is a media resource

Jakub: Firefox treats this separately, it is not a page
... headers are modified, so it works
... but we cannot have custom controls, so the UA cannot really render the fragment

<silvia> you mean: the plugin cannot render the fragment?

Raphael: it can ... with some tricks
... removing the default controls of firefox
... and use the contextual menu to enforce custom controls
... the issue Silvia is that Firefox does not consider http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.ogv as a page
... you need to hide the default controls and enforce yours

<silvia> yes, I understood that - I was wondering how you managed to get around it

Room applauses Jakub

<silvia> I applaud Jakub, too :)

3. Media Fragments URI syntax

ACTION-152?

<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

<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/152

When the action has been given: http://www.w3.org/2010/03/09-mediafrag-minutes.html#action01

<Yves> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#naming-track

Yves: OK, I need to modify the grammar

Raphael: the semantics is a and, right?

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

Raphael: I have an announcement

ACTION-119?

<trackbot> ACTION-119 -- Yves Lafon to request admins to set up a cvs notifications mailing list and notifications -- due 2009-10-14 -- OPEN

<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/119

The mailing list has been setup

It is: member-media-fragment-notifications@w3.org

scribe: you must subscribe to it if you wish to get notifications in our repository

<Yves> http://lists.w3.org/Archives/Member/member-media-fragment-notifications/

scribe: for example, get notifications for all the demo files uploaded this morning
... but also chaanges in the spec
... this is an opt-in mailing list, so far, only Yves and I are subscribed

close ACTION-119

<trackbot> ACTION-119 Request admins to set up a cvs notifications mailing list and notifications closed

Raphael: Yves is working now on the ACTION-152
... formal grammar fixed now for the URI syntax
... allow multiple 'track=' in the URI
... nothing to change in the header syntax since Silvia has already foreseen the case
... i.e: track-ranges-specifier = trackprefix "=" trackparam *( ";" trackparam )

close ACTION-152

<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

ACTION-160?

<trackbot> ACTION-160 -- Yves Lafon to send an email reporting the issue for track names -- due 2010-04-14 -- OPEN

<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/160

Yves: mail has not been sent
... I will explain the issue

we are seeing more and more IRIs, so what should be the encoding of a fragment in a IRI?

scribe: how do we specify that track names should be encoded in UTF-8 if the IRIs is encoded differently ?

Yves: there are mappings between IRIs and URIs
... IRIs can be a different character set

<Yves> http://www.ietf.org/rfc/rfc3987.txt

Jack is giving an example mixing latin2 (Polish with /L), utf8 and Big5 (Chinese) encoding

Jack: I think it is not a unique problem for us
... I'm pretty sure actually
... so other groups must have faced this issue

Raphael: suggest that Yves's action is transformed into a mail to the Internationalization WG cc-ing us to flag the issue we have

<Yves> http://tools.ietf.org/wg/idnabis/

Raphael: suggest that Yves does this action after lunch break

ACTION-170?

<trackbot> ACTION-170 -- Yves Lafon to send an email about metadata headers and 206 responses -- due 2010-06-09 -- OPEN

<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/170

See Yves's email at http://lists.w3.org/Archives/Public/public-media-fragment/2010Jun/0007.html

See Silvia's understanding of the issue: http://lists.w3.org/Archives/Public/public-media-fragment/2010Jun/0009.html

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
... works with if-range and etag

<Yves> http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-09#section-5.3

Yves: second issue, drawing on the blackboard
... request a first fragment (request 1) triggers a reply with a Content-Range-Mapping header
... request a second fragment (request 2) triggers another reply with another Content-Range-Mapping header
... the Content-Range-Mapping is an Entity Header ... so it will be saved
... that's why I think we should NOT add any new headers in the spec
... summary, IF-RANGE is an orthogonal issue ... it is just to ensure that we have a fresh copy
... headers apply to the full resource

Jack: I understand the issue ... but we need paragraphs in the spec
... perhaps a new section of how caches must work, similar to section 7 for clients
... drawing will put in the wiki in lunch

Raphael: after lunch break, continuing on ACTION-170
... now, we have a drawing on the wiki
... see http://www.w3.org/2008/WebVideo/Fragments/wiki/File:F2f-jun2010-cr-crm-caching.jpg
... I think the discussion should now interest both Silvia and Conrad ... we are discussing a proper use of the Content-Range-Mapping header

ACTION-170?

<trackbot> ACTION-170 -- Yves Lafon to send an email about metadata headers and 206 responses -- due 2010-06-09 -- OPEN

<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/170

Jack: further explanation ... in the 3rd solution of the picture, the CR has just bytes ... while the CRM has both bytes + seconds

Conrad: your problem is you have just one request header (Range) and several reply headers (for handling caching)

Yves: if you have a Vary header, the cache will not cache anything at all

<Yves> Req1: Get time range 0-5, reply bytes 0-2048 + crm 0-5, a nmf-aware cache will cache this

<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

<Yves> req3: get byte range 0-4096, cache will reply with bytes 0-4096 with crm 5-10

<Yves> so the client will think that 5-10s == 0-4096 bytes which is wrong

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

<Yves> hance the need to put in CRM 2048-4096 = 5s-10s

<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?

Jack: is it not a corner case?

<silvia> conrad: yes, that's the idea

<Yves> an UA that understands time ranges can do what it wants

<Yves> an UA knowing only byte ranges won't give misleading information

<Yves> that's the only point

<conrad> well, a ua that only understands byte ranges isn't going to make the time range request in the first place

<Yves> Adding a Vary: Range, on each request, the cnon-mf aware cache will clear its current entry

<conrad> Yves, I don't understand what you mean by "can do what it wants"

<conrad> obviously the only thing to do is to accept the body and play it

<conrad> yes, i wouldn't vary on range on this response

<conrad> yes, i wouldn't vary on range on this request

<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)

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 response

<silvia> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-protocol-server-mapped-default

Raphael: we are discussing now recipes described in 5.2.2.1 and 5.2.2.2
... headlines are wrong, since all 5.2.2.x solutions are cacheable in some sense

Davy: CRM is useless in the case of a 200 response
... or if the UA makes a byte ranges request

Raphael: we need to add a paragraph for explaining this clearly in the spec
... the rationale for the introduction of this new header

<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:

<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.

<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.

RESOLUTION: adopt the third solution drawn on the wiki

<scribe> ACTION: Yves to modify the ABNF syntax of the Content-Range-Mapping header to take into account this resolution [recorded in http://www.w3.org/2010/06/15-mediafrag-minutes.html#action01]

<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].

Silvia: I support very much a section for caches

Jack: I would suggest we rename the section 7 into a "Note for Implementers"
... with 7.1: For UA implementers ... how to render Media Fragments
... with 7.2: For cache implementers ... how to handle Media Fragments

<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

<conrad> if you can do that, it's probably usefully cacheable, and streamable

<scribe> ACTION: Jack to work on the existing Section 7, and draft 7.2 [recorded in http://www.w3.org/2010/06/15-mediafrag-minutes.html#action02]

<trackbot> Created ACTION-172 - Work on the existing Section 7, and draft 7.2 [on Jack Jansen - due 2010-06-22].

close ACTION-170

<trackbot> ACTION-170 Send an email about metadata headers and 206 responses closed

Jack: to conrad, bytes range are absolute with respect to the original resource, so no cascading

4. Protocol Handling

Wim: issue for non multiplexed file ... the video is in the beginning and the audio starts in the middle
... the time ranges correspond to multiple byte ranges
... how this should be represented in the CRM header?

Erik: Wim, can you write an example on IRC?

<silvia> Wim: http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-protocol-server-mapped-setup is your answer

<Wim> Content-Range-Mapping: t:npt 10-20;include-setup=bytes 0-2000,4000-10000/20000

<silvia> ah, yes, that needs to be included in CRM with multiple byte ranges - that's correct IMHO

<Wim> Content-Range-Mapping: t:npt 10-20/0-38;include-setup=bytes 0-2000,4000-10000/20000

<silvia> no, you cannot ask for multiple time ranges

<davy> 0-38 is the total duration

<silvia> ah,ok, fine

<silvia> how about this:

<silvia> Content-Range-Mapping: t:npt 10-20/0-38;include-setup eq bytes 0-2000,4000-10000/20000

<silvia> a keyword "eq" in the middle with spaces around

<conrad> in 5.2.2.3, can you receive multiple byte-ranges in the Range-Redirect response header?

<conrad> ah yes you can :)

<conrad> (the example only had one)

<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

<silvia> Content-Range-Mapping: (t:npt 10-20/0-38;include-setup) eq (bytes 0-2000,4000-10000/20000) ?

Raphael: then replace 'eq' by 'equal'?

<silvia> Content-Range-Mapping: <t:npt 10-20/0-38;include-setup> eq <bytes 0-2000,4000-10000/20000>

<silvia> Yves: it looks a bit ugly, to be honest...

Raphael: no need for parenthesis

<Yves> CRM: t:npt 10-20/0-38;include-setup = bytes 0-2000,4000-1000/2000

<silvia> Content-Range-Mapping: t:npt 10-20/0-38;include-setup equals bytes 0-2000,4000-10000/20000

<Yves> a=b is usually readable

<silvia> CRM: (t:npt 10-20/0-38;include-setup) = (bytes 0-2000,4000-1000/2000)

<Yves> and more efficient

Wim: '=' is better to parse

<Yves> only one = is allowed => no need for parenthesis

<Yves> remember that it has to be parsed by machines

We need a primary separator (e.g. =) and a secondary one (the ';')

<Yves> (and debugged only by knowledgeable humans :) )

<hackerjack> Would this work? CRM: t:npt 10-20/0-38;include-setup bytes 0-2000,4000-1000/2000

<silvia> please let's have a separator or some soft

<hackerjack> ok, you've convinced me:-)

First option: Content-Range-Mapping: t:npt 10-20;include-setup=bytes 0-2000,4000-10000/20000

<Yves> why not removing ';'

<Yves> Content-Range-Mapping: t:npt 10-20 include-setup=bytes 0-2000,4000-10000/20000

<FD> Content-Range-Mapping: t:npt 10-20,include-setup=bytes 0-2000,4000-10000/20000

Jack: CRM: (t:npt 10-20/0-38;include-setup) (bytes 0-2000,4000-1000/2000)

<Yves> {} instead?

<davy> Content-Range-Mapping: t:npt 10-20 include-setup>bytes 0-2000,4000-10000/20000 ?

<silvia> if we remove ';' , we should just make it a series of statements:

<silvia> Content-Range-Mapping: t:npt 10-20 include-setup bytes 0-2000,4000-10000/20000

<Yves> silvia, yes hence the { token* }

<hackerjack> §, anyone?

PROPOSES: CRM: {t:npt 10-20/0-38;include-setup} {bytes 0-2000,4000-1000/2000}

<Yves> better with an = in the middle (clearer in the intend), but no big deal if it's not there

PROPOSED: CRM: {t:npt 10-20/0-38;include-setup}={bytes 0-2000,4000-1000/2000}

<davy> +1

<erik> +1

<Yves> sounds good to me

<Wim> +1

<silvia> Content-Range-Mapping: t:npt 10-20; include-setup; bytes 0-2000,4000-10000/20000

<hackerjack> -0

<silvia> based on:

<silvia> Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1

<silvia> I checked how other headers work at http://en.wikipedia.org/wiki/List_of_HTTP_headers

<silvia> ok

<silvia> +1 on the above

<silvia> it's the talkative header ;)

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}"

ACTION-166?

<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

<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/166

Yves: I will produce the code for checking the grammar of the ABNF syntax of the headers as for the URI syntax

close ACTION-166

<trackbot> ACTION-166 Review the ABNF syntax of the HTTP headers introduced by the Media Fragment URI spec closed

<scribe> ACTION: Yves to produce the code that will check the grammar of both the URI syntax and the Headers syntax [recorded in http://www.w3.org/2010/06/15-mediafrag-minutes.html#action03]

<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].

Jack: there is common bits between the uri syntax and the header syntax
... could we split this into 3 blocks: common syntax, uri syntax and header syntax ?

<scribe> ACTION: Yves to produce the common syntax block [recorded in http://www.w3.org/2010/06/15-mediafrag-minutes.html#action04]

<trackbot> Created ACTION-174 - Produce the common syntax block [on Yves Lafon - due 2010-06-22].

<silvia> we are also repeating some code from the HTTP spec

<silvia> so it's 4 blocks really

Yves: we are importing some stuff as a convenience ... but the normative is in the HTTP spec referenced

<silvia> except where we extend it ;)

ACTION-137?

<trackbot> ACTION-137 -- Jack Jansen to check that section 5.2 is implementable using the protocol -- due 2010-02-10 -- OPEN

<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/137

We found back what was the ACTION:-)

It is actually to read and review the _current_ section 5.1!

Jack: I will put this into the section 7!
... I think the section 7 will not be normative ... but this important stuff that needs to be said

Raphael: ACTION-137 is ongoing
... now rephrased into: Merge the content of section 5.1in the future section 7 (and check whether it is implementable using the protocol?)

<Yves> 3:13pm here

Jack: looking back at some past actions we should close

drop ACTION-34

<hackerjack> trackbot, help

<trackbot> See http://www.w3.org/2005/06/tracker/irc for help

<hackerjack> thanks!

close ACTION-34

<trackbot> ACTION-34 Look at python-url library to see whether he could implement the logic on client side closed

comment ACTION-35 we might come back to these if we are lacking implementations, but no resources on this now

close ACTION-35

<trackbot> ACTION-35 Look at curl and/or wget to see whether the logic could be implemented on client side closed

5. Other dimensions (track, id, xywh)

Jack: I would like to make a disctinction between the URI syntax part and the HTTP handling part
... the first being well thought, sort-of
... the second hasn't been enough discussed

Raphael: let's talk first about the xywh dimension
... we have implementation on client (Jakub)
... purely on client side
... nothing transmitted over the wire

<silvia> I prefer it to stay that way actually

Jack: xywh will only be standardized in URI and not in protocol

Raphael: yes silvia, question is whether we put strong statements or not in the spec

<silvia> reason being that right now there are no codecs I believe where spatial cropping can be done by byte ranges

<silvia> but we should add a note that it is possible to extend this in the future?

<Yves> well there is no need to bind that to byte ranges

<Yves> but not saying anything means that the door is not closed

<silvia> agreed

OK, we have the text already written in the spec

scribe: for the explanation

"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: "

Perfect!

Jack: two use cases for this, the grey overlay and the sprite that CSS people want to do

Raphael: track dimension
... clear use cases in the accessibility community

Davy: implementation problem with tracks when we want to cache it ... too many characters to store!

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

Davy: how Ninsuna currently works, is via the '?' ... a redirect from a hash to the query

Jack: should we write this in our new section 7?

Raphael: discussion how to handle track and id ... appealing solution from Jack

<hackerjack> Silvia, you still here?

Raphael: do a redirect in the HTTP sense (30x)
... to a URI with a query

<silvia> a redirect can always be performed - I think we should describe this generally

Raphael: we are documenting the solution ... which in a nutshell comes back to always do a redirection when there is track or id selection
... solution is cacheable but not 'mergeable'

<silvia> "mergeable"?

<silvia> you can always combine a query with a fragment request

yeah yeah, we are not talking about this

6. Handling track and id

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
... Case 1: URI requested is under the form: http://www.example.com/video.ogg#track=1 or http://www.example.com/video.ogg#track=myaudio
... The UA sends a Range request to the server
... this request has a Range header, "Range: track=myaudio"
... the server sends a 30x reply indicating a Redirect
... this reply has a Location header, "Location: http://www.example.com/video.ogg?track=myaudio"
... (where the # has been transformed by a ? per server decision)
... the UA sends another request, a normal one this time: http://www.example.com/video.ogg?track=myaudio
... the server will serve a complete new resource (per the use of the query parameter) with a 200 reply
... in addition, we enforce that the second reply contains a Link header, pointing to the original resource, i.e. http://www.example.com/video.ogg
... Case 2: Combination of track selection and time ranges
... URI requested under the form: http://www.example.com/video.ogg#track=myaudio&t=20,50
... The UA sends a Range request to the server
... this request has again a Range header, e.g., "Range: track=myaudio,t:npt=20-50"

the server sends a 30x reply indicating a Redirect because of the presence of the track selection

scribe: this reply has a Location header that points to a Media Fragment URI, "Location: http://www.example.com/video.ogg?track=myaudio#t=20,50"
... the UA sends another request, a RANGE request because of the presence of the '#': http://www.example.com/video.ogg?track=myaudio#t=20,50
... the server will serve a Partial Content reply (206) of a newly constructed resource
... in addition, we enforce that the second replu contains a Link header, pointing to the original resource, i.e. http://www.example.com/video.ogg

s/replu.reply

s/replu/reply

Raphael: In summary, we _always_ handle the track and id selections by a Redirection
... we keep the original author intention of using a hash by putting back a link to the original resource with the Link header
... this solution is cacheable by the current infrastructure
... This needs to be approved tomorrow

7. Housekeeping

close ACTION-169

<trackbot> ACTION-169 Reserve the bridge for 15&16 June mediafrag f2f closed

<Yves> just finishedchanges for Content-Range-Mapping, including examples

<Yves> can someone check this? (especially examples, the 307 case of remapping being of interest)

<scribe> ACTION: Yves to update the grammar parsing automatically generated code for the URI syntax [recorded in http://www.w3.org/2010/06/15-mediafrag-minutes.html#action05]

<trackbot> Created ACTION-175 - Update the grammar parsing automatically generated code for the URI syntax [on Yves Lafon - due 2010-06-22].

ACTION-70?

<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

<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/70

close ACTION-137

<trackbot> ACTION-137 Merge the content of section 5.1in the future section 7 (and check whether it is implementable using the protocol?) closed

close ACTION-172

<trackbot> ACTION-172 Work on the existing Section 7, and draft 7.2 closed

ALL: we need to review the section 7

close ACTION-70

<trackbot> ACTION-70 Commit in CVS (code directory) his python code doing the parsing on client side of the media fragment closed

close ACTION-160

<trackbot> ACTION-160 Send an email to the Internationalization WG + us reporting the issue for track names closed

See: http://lists.w3.org/Archives/Public/public-media-fragment/2010Jun/0022.html

close ACTION-171

<trackbot> ACTION-171 Modify the ABNF syntax of the Content-Range-Mapping header to take into account this resolution closed

Tomorrow: come back to the discussion on handling tracks and id
... go through all ISSUES
... + demo of test cases framework from Davy / Wim

[meeting adjourned]

- DRAFT -

Media Fragments Working Group Teleconference

15 Jun 2010

Attendees

Contents