See also: IRC log
<trackbot> Date: 15 June 2010
<scribe> scribe: raphael
<scribe> scribenick: raphael
The agenda is at http://www.w3.org/2008/WebVideo/Fragments/wiki/SixthF2FAgenda
scribe: agenda approved
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 :)
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
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
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) ?
<Yves> let's use <...>
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
+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
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
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
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]
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/mediua/media/ Succeeded: s/showinf/showing/ FAILED: s/???/Wim/ Succeeded: s/that Apache/that the server/ Succeeded: s/sililar/similar/ Succeeded: s/??/Wim/ Succeeded: s/respnse/response/ Succeeded: s/or/of/ Succeeded: s/and server (Ninsuna)// WARNING: Bad s/// command: s/replu.reply FAILED: s/replu/reply/ Found Scribe: raphael Inferring ScribeNick: raphael Found ScribeNick: raphael Found Scribe: Raphael Found ScribeNick: Raphael WARNING: Replacing list of attendees. Old list: +33.4.93.00.aaaa Meeting_Room New list: +61.2.801.2.aaaa silvia Default Present: +61.2.801.2.aaaa, silvia WARNING: Replacing previous Present list. (Old list: Jakub, Jack, Yves, Raphael, Erik, Davy, Wim, Franck, Silvia_(remote)) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ Jacob, Jack, Yves, Raphael, Erik, davy, Wim, Franck, Silvia Present: Jacob Jack Yves Raphael Erik davy Wim Franck Silvia Regrets: Michael Agenda: http://www.w3.org/2008/WebVideo/Fragments/wiki/SixthF2FAgenda Found Date: 15 Jun 2010 Guessing minutes URL: http://www.w3.org/2010/06/15-mediafrag-minutes.html People with action items: jack yves[End of scribe.perl diagnostic output]