07:42:29 <RRSAgent> RRSAgent has joined #mediafrag
07:42:29 <RRSAgent> logging to http://www.w3.org/2010/06/16-mediafrag-irc
07:42:31 <trackbot> RRSAgent, make logs public
07:42:31 <Zakim> Zakim has joined #mediafrag
07:42:33 <trackbot> Zakim, this will be IA_MFWG
07:42:33 <Zakim> ok, trackbot; I see IA_MFWG()3:00AM scheduled to start 42 minutes ago
07:42:34 <trackbot> Meeting: Media Fragments Working Group Teleconference
07:42:34 <trackbot> Date: 16 June 2010
07:43:05 <davy> davy has joined #mediafrag
07:44:37 <FD> FD has joined #mediafrag
07:45:46 <erik> erik has joined #mediafrag
07:46:27 <Yves> Chair: Erik, Raphaël
07:47:05 <Yves> Present: Jack, Yves, Raphaël, Erik, Davy, Wim, Frank
07:47:43 <Wim> Wim has joined #mediafrag
07:48:28 <hackerjack> hackerjack has joined #mediafrag
07:49:51 <erik> agenda: http://www.w3.org/2008/WebVideo/Fragments/wiki/SixthF2FAgenda
07:50:03 <erik> regrets: Michael
07:50:18 <Yves> SCribe: jack
07:50:28 <Yves> ScribeNick: hackerjack
07:52:19 <raphael> raphael has joined #mediafrag
07:53:43 <hackerjack> agenda: http://www.w3.org/2008/WebVideo/Fragments/wiki/SixthF2FAgenda
07:54:19 <Zakim> IA_MFWG()3:00AM has now started
07:54:26 <Zakim> +Meeting_Room
07:54:28 <hackerjack> agenda: http://www.w3.org/2008/WebVideo/Fragments/wiki/SixthF2FAgenda
07:54:36 <hackerjack> trackbot start teleconf
07:54:37 <RRSAgent> I have made the request to generate http://www.w3.org/2010/06/16-mediafrag-minutes.html raphael
07:58:19 <hackerjack> Raphael: About Silvia's mail of yesterday: BNF is incomplete when only the "include-setup" is returned.
08:00:22 <hackerjack> All: agree. Yves to fix it now.
08:00:40 <raphael> Topic: 1. Protocol Handling (cont.)
08:03:49 <hackerjack> Erik: Let's revisit the redirect idea for track and id we discussed yesterday.
08:04:31 <hackerjack> ... for id it seems to be a good idea, but for track we could go both ways (redirect or direct implementation)
08:07:24 <raphael> Room: discussing again the pro/cons of the track + id handling
08:07:36 <raphael> ... track is now handled as ID, and not as time
08:08:15 <raphael> ... the redirect to query is a fallback solution just because the proble is that we will have too many characters in HTTP headers
08:09:52 <raphael> Raphael: should we document two solutions for handling track ... one using the redirect and another one similar to time?
08:10:11 <raphael> Jack: well, in this case, we are re-introducing the problem for caching cascading projections
08:10:35 <raphael> Erik: the only cascading problem will be track + time
08:19:15 <raphael> Jack: rationale, if we go the redirect way, the spec is finished today, and we can take it out
08:19:36 <raphael> ... if we go with Davy's solution, then more work is needed, we do not know how cache will behave
08:20:43 <raphael> Jack: most of the use cases will be time selection, some will be track selection, combination will be even rarer
08:22:53 <raphael> Jack: how robust is our current text for caching tracks? We need more implementation experience
08:28:12 <hackerjack> All: discussion about cacheability (by classic caches) of multipart
08:28:37 <Zakim> +silvia
08:29:38 <hackerjack> Erik: maybe we shoulnd't worry too much about old-style caches: there will be a strong push towards mf-aware (once mf is popular)
08:29:54 <raphael> Discussing: http://www.w3.org/2010/06/15-mediafrag-minutes.html#item06
08:33:02 <FD> FD has joined #mediafrag
08:42:09 <hackerjack> Jack: explaining the issues of yesterday and this morning to Silvia, and sketching tradeoffs (elegance versus quick publishing)
08:42:51 <hackerjack> Silvia: we shouldn't worry overmuch about cache implementation in our LC spec. We need implementations before we can be
08:42:57 <hackerjack> ... sure our text is corect.
08:43:03 <hackerjack> s/corect/sorrect
08:47:34 <hackerjack> Silvia: issue with redirect, specifically with redirect leading to new resource.
08:47:47 <hackerjack> Jack: but client knows about the linking to the old one.
08:47:52 <hackerjack> Silvia: that is a hack.
08:49:42 <silvia> Silvia: I think that if you have a #track URL in the browser and get redirected to the ?track URL, it may not remember the context, because you have loaded a new resource
08:49:58 <silvia> … so, getting back to the original resource and its tracks may be impossible
08:50:48 <silvia> … also, I am not too worried about these things yet, because I would wait and see what browser vendors implement
08:51:10 <silvia> … it is good for us to identify these issues, but I'm not sure we can solve them fully
08:51:24 <silvia> .. without implementations we won't have the answer to everything now
08:51:56 <silvia> … for #track, I would offer both options to browser vendors, then see how they go ;)
08:54:14 <raphael> OK Silvia
08:54:34 <raphael> we plan to enforce also the use of a Link header ... so context towards the original resource is here!
09:00:36 <raphael> Silvia:  http://www.web-polygraph.org/docs/userman/ranges.html <- looks like it supports multiple byte ranges
09:00:43 <raphael> Silvia:  but that might be a server and not a proxy...
09:06:12 <silvia> 5.2 has the following paragraph:
09:06:15 <silvia> It is possible to add an additional HTTP response header called "Link" that refers the new resource back to the original resource and enables the UA to retrieve further information about the original resource, such as its full length. In this case, the user agent is also enable to choose to display the dimensions of the primary resource or the one created by the query.
09:06:32 <hackerjack> Raphael: proposal. First, we document the redirect option, specifically as an option (to be used at the server's discretion) in stead of the "real" implementation
09:07:22 <silvia> ok
09:07:28 <hackerjack> Raphael: second,
09:08:42 <hackerjack> ... we make sure that the spec correctly specifies fragmenting of tracks
09:10:27 <hackerjack> ... third, similar for ID
09:15:22 <silvia> I think a web browser has actually 3 options:
09:15:33 <silvia> … 1. use byte ranges
09:15:44 <silvia> … 2. use redirect
09:15:55 <silvia> … 3. do locally
09:17:27 <hackerjack> silvia, you dropped from the audio
09:20:27 <FD> FD has joined #mediafrag
09:23:35 <hackerjack> All: discussion about whether lots of small fragments will work for the clients anyway.
09:24:39 <hackerjack> Silvia: talked to browser vendors, they will probably get whole resourcce, because their decoders may not handle it
09:25:16 <silvia> zakim, mute me
09:25:16 <Zakim> silvia should now be muted
09:40:17 <RRSAgent> I have made the request to generate http://www.w3.org/2010/06/16-mediafrag-minutes.html raphael
09:40:45 <raphael> scribenick: raphael
09:40:59 <Zakim> -silvia
09:41:20 <raphael> Summary: for the 3 dimensions, time, track and id, they will be a double mechanism described in the protocol
09:41:33 <raphael> ... either a direct way as it is described in the spec
09:42:27 <raphael> ... or as a redirect (30x reply) pointing to the same request that replace the # by the ?
09:43:05 <raphael> ... the second server reply MAY or MUST? contain a Link header pointing to the original resource the new one is derived from
09:47:17 <raphael> PROPOSED: Documenting in the spec the redirect mechanism in a new section 5.1.3 (that will point to 5.2) as an option (to be used at the server's discretion) and we make sure that the reader understands the two possible options 5.1.2 and 5.1.3 at server discretion
09:51:06 <raphael> Jack: proposed headline for new section 5.1.3 = Server triggered redirect
09:58:25 <hackerjack> Davy: but there is another issue with a redirect. The server has no way to communicate to the client whether the returned new resource
09:58:48 <hackerjack> ... has the mf completely applied or not. In the latter case the client would still have work to do.
10:00:21 <Yves> issue with the redirect is fragment handling on the redirected resource 
10:08:11 <Yves> http://tools.ietf.org/html/draft-nottingham-http-link-header-10
10:08:47 <silvia> wouldn't the redirect be to e.g. video.ogv?track=video#t=10,20 - then sent to the server again by the client - then have all the appropriate headers?
10:10:40 <silvia> it's an actual HTTP redirect, right?
10:11:27 <raphael> Yes, it is a real redirect
10:12:07 <raphael> ... the issue is: imagine that the UA has just requested a track (#track=audio4)
10:12:26 <raphael> ... the server cannot extract the track, but send a 307 pointing to the full resource
10:12:57 <raphael> ... how the UA knows whether the redirects points to the track it has originally requested or to the full resource?
10:13:23 <raphael> ... Ninsuna proxy currently works like this, send a redirecto to the full resource when it cannot extract the fragments
10:13:45 <silvia> but ours has a link header?
10:13:50 <raphael> ... idea would be to add a link header in the 307 reply to convey this information
10:14:15 <raphael> I'm talking of the first reply, the 307, not the second one with the actual data which has a Link header
10:15:42 <raphael> Yves: for the second reply, I suggest we use the property named 'alternate'
10:15:51 <raphael> ... so syntax would be:
10:16:42 <raphael> Link: <http://www.example.com/video.ogg#track=audio4> alternate
10:17:53 <raphael> Jack: perhaps we should use another term, it seems to me a hack
10:18:07 <raphael> ... no, I fully agree now, Yves convinced me
10:18:33 <raphael> Yves: for the first reply, the 307, we need a new term
10:21:45 <raphael> ... e.g. fragment
10:21:51 <raphael> ... so syntax would be:
10:22:26 <raphael> Link: <http://www.example.com/video.ogg#track=audio4> fragment
10:22:43 <raphael> Location: http://www.example.com/video.ogv
10:23:01 <raphael>  Location: http://www.example.com/video.ogv?track=audio4
10:23:05 <raphael> Vary: *
10:23:14 <raphael> ... in order to not cache the 307 reply
10:25:37 <raphael> Raphael: the description of how it works should now be completed, back to the proposal
10:25:39 <raphael> PROPOSED: Documenting in the spec the redirect mechanism in a new section 5.1.3 (that will point to 5.2) as an option (to be used at the server's discretion) and we make sure that the reader understands the two possible options 5.1.2 and 5.1.3 at server discretion
10:25:44 <raphael> let's vote
10:26:00 <hackerjack> +1
10:26:08 <davy> +1
10:26:12 <Wim> +1
10:27:18 <raphael> +1
10:27:21 <erik> +1
10:29:21 <Yves> =1
10:29:35 <Yves> s/=/+/
10:29:36 <hackerjack> s/-1/+1
10:29:58 <hackerjack> rrsagent draft minutes
10:30:07 <silvia> +1
10:30:11 <raphael> RESOLUTION:  Documenting in the spec the redirect mechanism in a new section 5.1.3 (that will point to 5.2) as an option (to be used at the server's discretion) and we make sure that the reader understands the two possible options 5.1.2 and 5.1.3 at server discretion
10:30:24 <hackerjack> RRSAgent, draft minutes
10:30:24 <RRSAgent> I have made the request to generate http://www.w3.org/2010/06/16-mediafrag-minutes.html hackerjack
10:31:42 <raphael> ACTION: Davy to edit a new section 5.1.3 named "Server triggered redirect" that documents fully this solution
10:31:42 <trackbot> Created ACTION-176 - Edit a new section 5.1.3 named "Server triggered redirect" that documents fully this solution [on Davy Van Deursen - due 2010-06-23].
10:33:20 <hackerjack> Erik: admin stuff. If we stop the normal agenda at 1400 that gives Davy time to do the edits, us all to wrap up, and end at 5.
10:35:26 <hackerjack> Raphael: let's drop test cases, not important for LC
10:36:31 <hackerjack> Raphael: proposal: we allow for a testcase f2f in september, if needed.
10:37:29 <hackerjack> Raphael: proposal: after lunch we do the "wednesday morning agenda".
10:37:49 <raphael> [lunch break]
10:39:58 <RRSAgent> I have made the request to generate http://www.w3.org/2010/06/16-mediafrag-minutes.html raphael
11:02:04 <Zakim> -Meeting_Room
11:02:05 <Zakim> IA_MFWG()3:00AM has ended
11:02:05 <Zakim> Attendees were Meeting_Room, silvia
11:21:18 <raphael> scribenick: raphael
11:21:31 <raphael> Topic: 2. ISSUE-4: Discovery of Track and Named fragments
11:29:39 <Zakim> Zakim has left #mediafrag
11:32:26 <raphael> ISSUE-4?
11:32:26 <trackbot> ISSUE-4 -- Should we pre-define some track names? -- open
11:32:26 <trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/4
11:34:14 <raphael> Raphael: http://www.w3.org/WAI/PF/HTML/wiki/Media_MultitrackAPI
11:34:27 <raphael> ... how do we know which tracks are available for selection
11:34:42 <raphael> ... could be extended to, how do we know which id/names are available for selection
11:35:13 <raphael> Yves: why do we care?
11:35:30 <raphael> ... our task is to enable the construction of the selection and the protocol handling
11:35:42 <raphael> ... how the discovery is performed does not matter too us
11:37:08 <raphael> Jack: all what we are saying is that track names are UTF-8 strings
11:37:10 <silvia> I agree with Yves - I think with point to things like ROE and  the JavaScript API, we have done all we can to propose a solution to discovery of track names
11:45:37 <raphael> Jack: we all agree, let's replace the ed note in the section 4.3.3 by a paragraph stating that they are no pre-defined track names
11:46:13 <raphael> ... but we mention the existing discovery mechanism such as ROE, Media Annotations, HTML5 MediaMultiTrack API
11:46:46 <raphael> Davy: I'm editing the spec right now
11:46:47 <hackerjack> Raphael: ok, all agreed, Davy will fix the text
11:46:54 <raphael> Raphael: can we close this issue?
11:47:26 <silvia> yes, please
11:48:23 <raphael> comment ISSUE-4 track names discovery is handled by others and we list example techniques
11:48:27 <raphael> close ISSUE-4
11:48:27 <trackbot> ISSUE-4 Should we pre-define some track names? closed
11:48:57 <raphael> Topic: 3. ISSUE-5
11:49:01 <raphael> ISSUE-5?
11:49:01 <trackbot> ISSUE-5 -- Handling spatial cropping requires information at client-side -- open
11:49:01 <trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/5
11:49:38 <raphael> Raphael: is this clear that in the case of the spatial dimension, nothing is sent to the server?
11:49:42 <raphael> Davy: yes
11:50:09 <raphael> ... in 5.1.2
11:50:11 <raphael> ... spatial media fragments are typically not expressible in terms of byte ranges. Spatial fragment extraction would thus require transcoding operations resulting in new resources rather than fragments of the original media resource. As described in section 3 URI fragment and URI query, spatial fragment extraction is in this case better represented by URI queries. 
11:50:39 <raphael> comment ISSUE-5 not relevant anymore
11:50:46 <raphael> close ISSUE-5
11:50:46 <trackbot> ISSUE-5 Handling spatial cropping requires information at client-side closed
11:51:20 <raphael> Topic: 4. ISSUE-6
11:51:27 <raphael> ISSUE-6?
11:51:27 <trackbot> ISSUE-6 -- Temporal clips that require transcoding -- open
11:51:27 <trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/6
11:56:40 <raphael> Erik: The section 3.1 is crystal clear
11:56:43 <raphael> ... Resources that are "fit" can therefore be addressed with a URI fragment. Resources that are "conditionally fit" can be addressed with a URI fragment with an additional retrieval action that retrieves the modified syntax elements but leaves the codec data untouched. Resources that are "unfit" require transcoding. Such transcoded media fragments cannot be addressed with URI fragments, but only with URI queries. 
11:56:50 <raphael> ... that closes the ISSUE
11:56:56 <jakub> jakub has joined #mediafrag
11:57:24 <raphael> ... editor note needs to be removed?
11:57:36 <raphael> ... link towards the UC doc needs to be modified
11:58:36 <raphael> ... no link to fix
12:01:28 <raphael> Davy: ed note removed
12:01:32 <raphael> close ISSUE-6
12:01:32 <trackbot> ISSUE-6 Temporal clips that require transcoding closed
12:02:07 <raphael> Jack: references are ugly, need to fix this
12:03:40 <hackerjack> Jack: Issue is: unmatch <a> element in the references, but xhtml document.
12:03:42 <raphael> Topic: 5. ISSUE-7
12:03:49 <raphael> ISSUE-7?
12:03:49 <trackbot> ISSUE-7 -- User Agent Media Fragment Resolution and Processing -- open
12:03:49 <trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/7
12:04:35 <raphael> Yves: this is the protocol description
12:04:39 <raphael> ... this is now done!
12:04:49 <RRSAgent> I have made the request to generate http://www.w3.org/2010/06/16-mediafrag-minutes.html raphael
12:05:06 <raphael> comment ISSUE-7 This is the protocol description now nicely described
12:05:16 <raphael> close ISSUE-7
12:05:16 <trackbot> ISSUE-7 User Agent Media Fragment Resolution and Processing closed
12:05:37 <raphael> Topic: 6. ISSUE-12
12:05:42 <raphael> ISSUE-12?
12:05:42 <trackbot> ISSUE-12 -- What's the relationship between Images (CSS) Sprites and the spatial dimension of the Media Fragments URI scheme? -- open
12:05:42 <trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/12
12:07:09 <raphael> Raphael: use of the spatial dimension for highlighting region (current implementation) or cropping (sprite)
12:07:19 <raphael> Jack: this is 2 different use cases
12:07:36 <raphael> Yves: no, the first intent is to define a region ... and not to define what to do with it
12:08:03 <raphael> Jack: yes, but in the temporal case, we provide more information
12:08:20 <raphael> ... perhaps in Section 7, we should write, "unlike the temporal dimension ..."
12:09:34 <raphael> Jack: I sugges to edit Section 7.1 to clarify this ...
12:10:09 <silvia> I agree
12:10:16 <raphael> ... what I'm doing is changing the paragraph "For a spatial URI fragment, it is recommended to emphasize the spatial region during playback. For instance, the spatial region could be indicated by means of a bounding box or the background (i.e., all the pixels that are not contained within the region) could be blurred or darkened. "
12:10:36 <raphael> ... to state we have two use cases: 1/ highlight 2/ sprite
12:17:17 <raphael> Jack: done
12:17:42 <raphael> comment ISSUE-12: the third paragraph of Section 7.1 has been updated
12:17:46 <raphael> close ISSUE-12
12:17:46 <trackbot> ISSUE-12 What's the relationship between Images (CSS) Sprites and the spatial dimension of the Media Fragments URI scheme? closed
12:22:04 <raphael> Topic: 7. Section 4.1
12:22:31 <raphael> Raphael: is the pseudo algorithm written by Philip useful?
12:30:26 <raphael> Yves and Jack: the pseudo code is useless
12:30:45 <raphael> Erik: +1
12:31:00 <raphael> Jack: we are not writing workaround for existing sloppy implementations
12:34:04 <raphael> Raphael: I see 3 options: a/ statu quo; b/ move 4.1.1 and 4.1.2 down in an Annex or in Section 7? ; c/ remove these 2 sub-sections
12:34:25 <Yves> b, c
12:34:40 <davy> b, c
12:34:43 <hackerjack> b, c (in order)
12:34:52 <raphael> b
12:34:59 <erik> b
12:36:30 <raphael> Jack: new Appendix D: notes on parsing media fragment URIs
12:36:44 <raphael> Jack: I'm editing
12:37:07 <raphael> ACTION: raphael to email philip about this decision
12:37:07 <trackbot> Sorry, couldn't find user - raphael
12:37:16 <raphael> ACTION: troncy to email philip about this decision
12:37:16 <trackbot> Created ACTION-177 - Email philip about this decision [on Raphaël Troncy - due 2010-06-23].
12:38:39 <RRSAgent> I have made the request to generate http://www.w3.org/2010/06/16-mediafrag-minutes.html raphael
12:43:28 <raphael> close ACTION-177
12:43:28 <trackbot> ACTION-177 Email philip about this decision closed
12:52:19 <raphael> Raphael: mail sent
12:52:50 <raphael> Jack: I'm moving the editorial note of Silvia in ex 4.1.2 into Section 7 and drafting a new paragraph
12:53:01 <raphael> Topic: 8. Internaitonalization
12:53:32 <raphael> Raphael: Yves sent an email yesterday to the i18n group
12:53:34 <raphael> ... see http://lists.w3.org/Archives/Public/public-media-fragment/2010Jun/0022.html
12:53:45 <raphael> ... I suggest to open an Issue for tracking this
12:54:08 <raphael> ISSUE: Media Fragment track names and IRIs
12:54:08 <trackbot> Created ISSUE-17 - Media Fragment track names and IRIs ; please complete additional details at http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/17/edit .
12:56:16 <raphael> Silvia suggested on the list to redefine the production rules in terms of rfc 3987 rather than 3986
12:56:23 <raphael> Yves: I think it would be more difficult
12:56:27 <raphael> ... we don't know the encoding, etc.
12:56:41 <raphael> ... let's i18n fix this which touches several groups
12:59:18 <raphael> Topic: 9. ISSUE-14
12:59:20 <raphael> ISSUE-14?
12:59:20 <trackbot> ISSUE-14 -- How to deal with embedded time stamps -- open
12:59:20 <trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/14
13:04:56 <raphael> Jack: for container-based timestamps (which may have gaps), we think there is no issue
13:05:03 <raphael> ... gaps will be preserved so to speak
13:06:03 <raphael> ... for the other case, smpte timestamps with labels ... it is almost as id
13:06:07 <raphael> ... there are many issues
13:06:29 <raphael> ... not being 0 based is one issue, but you can also have strange gaps
13:06:38 <raphael> ... unclear what a media player will do with it
13:16:07 <raphael> Jack: I'm adding a new sentence in the section 7.3
13:16:48 <raphael> ... "Embedded Timecodes: "
13:16:56 <raphael> ... in order to close this issue
13:23:02 <hackerjack> s/Embedded/SMPTE
13:23:18 <hackerjack> RRSAgent, draft minutes
13:23:18 <RRSAgent> I have made the request to generate http://www.w3.org/2010/06/16-mediafrag-minutes.html hackerjack
13:26:09 <raphael> Room: problem regarding the units requested versus the units used in the response
13:26:17 <raphael> ... should it be enforced to be the same?
13:26:27 <raphael> ... should we say something at all about this?
13:27:14 <raphael> Yves: we say nothing since we infer that people will use smpte time code know what they are doing
13:27:58 <Yves> ISSUE-14?
13:27:58 <trackbot> ISSUE-14 -- How to deal with embedded time stamps -- open
13:27:58 <trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/14
13:28:16 <raphael> close ISSUE-14
13:28:16 <trackbot> ISSUE-14 How to deal with embedded time stamps closed
13:29:46 <Yves> ISSUE-16?
13:29:46 <trackbot> ISSUE-16 -- Combining axis is probably not going to be done by LC, but we should write somewhere that this is doable -- open
13:29:46 <trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/16
13:30:54 <raphael> Davy: the biggest issue was with the spatial dimension
13:30:58 <Yves> issue-13?
13:30:58 <trackbot> ISSUE-13 -- Write a IETF draft for proposing how to register the fragment scheme for all media types -- open
13:30:58 <trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/13
13:31:21 <raphael> ... we can close it since we are doign combination now, e.g. track + time
13:31:29 <raphael> close ISSUE-16
13:31:29 <trackbot> ISSUE-16 Combining axis is probably not going to be done by LC, but we should write somewhere that this is doable closed
13:32:04 <raphael> Yves: I have discussion with larry masinter and IETF about this
13:32:18 <raphael> ... we don't need this for Last Call
13:32:22 <raphael> ... ongoing issue
13:32:38 <raphael> ... we need to figure out what would be the process, in our own spec, in a RFC, etc.
13:32:59 <raphael> Topic: 10. Last Call Resolution
13:33:04 <RRSAgent> I have made the request to generate http://www.w3.org/2010/06/16-mediafrag-minutes.html raphael
13:33:04 <hackerjack> +1
13:33:08 <Yves> +1
13:33:21 <raphael> PROPOSED: the document is good enough to be a Last Call
13:33:24 <davy> +1
13:33:24 <Yves> +1
13:33:27 <Wim> +1
13:33:28 <raphael> +1
13:33:28 <hackerjack> +1
13:33:29 <erik> +1
13:33:35 <raphael> Silvia has agrees also
13:33:41 <raphael> no objections
13:33:46 <Yves> s/agrees/agreed/
13:33:51 <erik> s/agrees/agreed
13:34:23 <Yves> see http://www.w3.org/2005/08/online_xslt/xslt?xmlfile=http://www.w3.org/2005/08/01-transitions.html&xslfile=http://www.w3.org/2005/08/transitions.xsl&docstatus=lc-wd-tr
13:35:00 <Yves> Silvia, please review the doc (the one by end of this week)
13:35:11 <raphael> RESOLUTION: Publish the document as a Last Call Working Draft next week
13:35:25 <raphael> Raphael: yves will complete his actions by Sunday
13:35:50 <raphael> ... davy will have finished 176 today
13:35:54 <raphael> ... we need internal review
13:35:58 <raphael> Erik: I suggest Silvia
13:37:08 <raphael> ACTION: Silvia to review the complete document, remove unnecessary editorial notes before publication
13:37:09 <trackbot> Created ACTION-178 - Review the complete document, remove unnecessary editorial notes before publication [on Silvia Pfeiffer - due 2010-06-23].
13:37:39 <RRSAgent> I have made the request to generate http://www.w3.org/2010/06/16-mediafrag-minutes.html raphael
13:45:03 <raphael> Raphael: we need to decide on which groups we want and wish to have reviews from
13:53:08 <raphael> ... MUST working groups: HTML WG, Media Annotations WG, SYMM, Semantic Web CG, Hypertext CG, TAG, IETF
13:53:35 <raphael> ... WISH to have additional reviews from: CSS, SVG, TimedText, I18N, Audio XG
13:54:39 <raphael> Yves: deadline for comments?
13:55:37 <raphael> ... end of August!
13:57:56 <raphael> Topic: 11. AOB
13:58:11 <raphael> Raphael: Media Annotations LCWD
13:58:17 <raphael> ... how do we make a group reply?
13:58:30 <raphael> ... or do we make individual replies?
13:59:11 <raphael> Jack: I want to read this with my media fragments hat on
13:59:23 <raphael> ... discuss by email about a group reply?
14:01:31 <raphael> jack: people comment on their own name
14:01:55 <raphael> ... write replies to our group when this is common issues for the MF WG
14:03:14 <Yves> p
14:03:19 <Yves> s/p//
14:04:08 <raphael> Raphael: LCWD of Media annotations: Ontology = http://www.w3.org/TR/2010/WD-mediaont-10-20100608/
14:04:18 <raphael> ... APi: http://www.w3.org/TR/2010/WD-mediaont-api-1.0-20100608/
14:05:34 <raphael> ... we provide a group reply with all the collected issues that interest the group
14:05:49 <raphael> ... we dedicate one of the upcoming telecon about this
14:08:45 <RRSAgent> I have made the request to generate http://www.w3.org/2010/06/16-mediafrag-minutes.html raphael
14:14:26 <erik> on behalf of the chairs ... a BIG thanks to all contributors of this F2F ... LC here we come :)
14:23:49 <raphael> Davy: section 5.1.3 now completed!
14:23:55 <raphael> Room: reviewing ...
14:23:56 <erik> Thx Davy!
14:24:10 <raphael> close ACTION-176
14:24:10 <trackbot> ACTION-176 Edit a new section 5.1.3 named "Server triggered redirect" that documents fully this solution closed
14:24:20 <RRSAgent> I have made the request to generate http://www.w3.org/2010/06/16-mediafrag-minutes.html raphael
14:24:58 <raphael> Frank: perhaps add in the reference section a ref to the Link Header
14:33:30 <davy> Added ref to the Web Linking draft
14:33:31 <RRSAgent> I have made the request to generate http://www.w3.org/2010/06/16-mediafrag-minutes.html raphael
14:35:24 <raphael> thanks davy
14:35:28 <raphael> Meeting successful
14:35:31 <raphael> [adjourned]
14:35:40 <RRSAgent> I have made the request to generate http://www.w3.org/2010/06/16-mediafrag-minutes.html raphael