W3C

Media Fragments Working Group Teleconference

16 Apr 2009

Agenda

See also: IRC log

Attendees

Present
conrad, michael, jack, erik, davy, frank_(canon_observer), raphael, dave_singer, silvia_(phone), yves_(phone)
Regrets
Chair
Erik, Raphael
Scribe
raphael

Contents


 

 

<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

1. Administrative

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

2. Yves/Silvia/Conrad: Specification discussion

* 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

discoverability

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

Numbers of documents

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

Summary of Action Items

[NEW] 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]
[NEW] 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]
[NEW] 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]
[NEW] 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]
[NEW] 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]
[NEW] 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]
[NEW] 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]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2009/04/17 19:32:10 $