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