W3C

- DRAFT -

Media Fragments Working Group Teleconference

16 Jun 2010

Agenda

See also: IRC log

Attendees

Present
Jack, Yves, Rapha�l, Erik, Davy, Wim, Frank
Regrets
Michael
Chair
Erik, Rapha�l
Scribe
jack

Contents


<trackbot> Date: 16 June 2010

<Yves> SCribe: jack

<Yves> ScribeNick: hackerjack

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

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

trackbot start teleconf

Raphael: About Silvia's mail of yesterday: BNF is incomplete when only the "include-setup" is returned.

All: agree. Yves to fix it now.

1. Protocol Handling (cont.)

Erik: Let's revisit the redirect idea for track and id we discussed yesterday.
... for id it seems to be a good idea, but for track we could go both ways (redirect or direct implementation)

<raphael> Room: discussing again the pro/cons of the track + id handling

<raphael> ... track is now handled as ID, and not as time

<raphael> ... the redirect to query is a fallback solution just because the proble is that we will have too many characters in HTTP headers

<raphael> Raphael: should we document two solutions for handling track ... one using the redirect and another one similar to time?

<raphael> Jack: well, in this case, we are re-introducing the problem for caching cascading projections

<raphael> Erik: the only cascading problem will be track + time

<raphael> Jack: rationale, if we go the redirect way, the spec is finished today, and we can take it out

<raphael> ... if we go with Davy's solution, then more work is needed, we do not know how cache will behave

<raphael> Jack: most of the use cases will be time selection, some will be track selection, combination will be even rarer

<raphael> Jack: how robust is our current text for caching tracks? We need more implementation experience

All: discussion about cacheability (by classic caches) of multipart

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)

<raphael> Discussing: http://www.w3.org/2010/06/15-mediafrag-minutes.html#item06

Jack: explaining the issues of yesterday and this morning to Silvia, and sketching tradeoffs (elegance versus quick publishing)

Silvia: we shouldn't worry overmuch about cache implementation in our LC spec. We need implementations before we can be
... sure our text is sorrect.
... issue with redirect, specifically with redirect leading to new resource.

Jack: but client knows about the linking to the old one.

Silvia: that is a hack.

<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

<silvia> … so, getting back to the original resource and its tracks may be impossible

<silvia> … also, I am not too worried about these things yet, because I would wait and see what browser vendors implement

<silvia> … it is good for us to identify these issues, but I'm not sure we can solve them fully

<silvia> .. without implementations we won't have the answer to everything now

<silvia> … for #track, I would offer both options to browser vendors, then see how they go ;)

<raphael> OK Silvia

<raphael> we plan to enforce also the use of a Link header ... so context towards the original resource is here!

<raphael> Silvia: http://www.web-polygraph.org/docs/userman/ranges.html <- looks like it supports multiple byte ranges

<raphael> Silvia: but that might be a server and not a proxy...

<silvia> 5.2 has the following paragraph:

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

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

<silvia> ok

Raphael: second,
... we make sure that the spec correctly specifies fragmenting of tracks
... third, similar for ID

<silvia> I think a web browser has actually 3 options:

<silvia> … 1. use byte ranges

<silvia> … 2. use redirect

<silvia> … 3. do locally

silvia, you dropped from the audio

All: discussion about whether lots of small fragments will work for the clients anyway.

Silvia: talked to browser vendors, they will probably get whole resourcce, because their decoders may not handle it

<raphael> scribenick: raphael

Summary: for the 3 dimensions, time, track and id, they will be a double mechanism described in the protocol
... either a direct way as it is described in the spec
... or as a redirect (30x reply) pointing to the same request that replace the # by the ?
... the second server reply MAY or MUST? contain a Link header pointing to the original resource the new one is derived from

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

Jack: proposed headline for new section 5.1.3 = Server triggered redirect

<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

<hackerjack> ... has the mf completely applied or not. In the latter case the client would still have work to do.

<Yves> issue with the redirect is fragment handling on the redirected resource

<Yves> http://tools.ietf.org/html/draft-nottingham-http-link-header+10

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

<silvia> it's an actual HTTP redirect, right?

Yes, it is a real redirect

scribe: the issue is: imagine that the UA has just requested a track (#track=audio4)
... the server cannot extract the track, but send a 307 pointing to the full resource
... how the UA knows whether the redirects points to the track it has originally requested or to the full resource?
... Ninsuna proxy currently works like this, send a redirecto to the full resource when it cannot extract the fragments

<silvia> but ours has a link header?

scribe: idea would be to add a link header in the 307 reply to convey this information

I'm talking of the first reply, the 307, not the second one with the actual data which has a Link header

Yves: for the second reply, I suggest we use the property named 'alternate'
... so syntax would be:

Link: <http://www.example.com/video.ogg#track=audio4> alternate

Jack: perhaps we should use another term, it seems to me a hack
... no, I fully agree now, Yves convinced me

Yves: for the first reply, the 307, we need a new term
... e.g. fragment
... so syntax would be:

Link: <http://www.example.com/video.ogg#track=audio4> fragment

Location: http://www.example.com/video.ogv
... http://www.example.com/video.ogv?track=audio4

Vary: *
... in order to not cache the 307 reply

Raphael: the description of how it works should now be completed, back to the proposal

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

let's vote

<hackerjack> +1

<davy> +1

<Wim> +1

+1

<erik> +1

<Yves> +1

<hackerjack> rrsagent draft minutes

<silvia> +1

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

<scribe> ACTION: Davy to edit a new section 5.1.3 named "Server triggered redirect" that documents fully this solution [recorded in http://www.w3.org/2010/06/16-mediafrag-minutes.html#action01]

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

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

<hackerjack> Raphael: let's drop test cases, not important for LC

<hackerjack> Raphael: proposal: we allow for a testcase f2f in september, if needed.

<hackerjack> Raphael: proposal: after lunch we do the "wednesday morning agenda".

[lunch break]

<scribe> scribenick: raphael

2. ISSUE-4: Discovery of Track and Named fragments

ISSUE-4?

<trackbot> ISSUE-4 -- Should we pre-define some track names? -- open

<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/4

Raphael: http://www.w3.org/WAI/PF/HTML/wiki/Media_MultitrackAPI
... how do we know which tracks are available for selection
... could be extended to, how do we know which id/names are available for selection

Yves: why do we care?
... our task is to enable the construction of the selection and the protocol handling
... how the discovery is performed does not matter too us

Jack: all what we are saying is that track names are UTF-8 strings

<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

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
... but we mention the existing discovery mechanism such as ROE, Media Annotations, HTML5 MediaMultiTrack API

Davy: I'm editing the spec right now

<hackerjack> Raphael: ok, all agreed, Davy will fix the text

Raphael: can we close this issue?

<silvia> yes, please

comment ISSUE-4 track names discovery is handled by others and we list example techniques

close ISSUE-4

<trackbot> ISSUE-4 Should we pre-define some track names? closed

3. ISSUE-5

ISSUE-5?

<trackbot> ISSUE-5 -- Handling spatial cropping requires information at client-side -- open

<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/5

Raphael: is this clear that in the case of the spatial dimension, nothing is sent to the server?

Davy: yes
... in 5.1.2
... 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.

comment ISSUE-5 not relevant anymore

close ISSUE-5

<trackbot> ISSUE-5 Handling spatial cropping requires information at client-side closed

4. ISSUE-6

ISSUE-6?

<trackbot> ISSUE-6 -- Temporal clips that require transcoding -- open

<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/6

Erik: The section 3.1 is crystal clear
... 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.
... that closes the ISSUE
... editor note needs to be removed?
... link towards the UC doc needs to be modified
... no link to fix

Davy: ed note removed

close ISSUE-6

<trackbot> ISSUE-6 Temporal clips that require transcoding closed

Jack: references are ugly, need to fix this

<hackerjack> Jack: Issue is: unmatch <a> element in the references, but xhtml document.

5. ISSUE-7

ISSUE-7?

<trackbot> ISSUE-7 -- User Agent Media Fragment Resolution and Processing -- open

<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/7

Yves: this is the protocol description
... this is now done!

comment ISSUE-7 This is the protocol description now nicely described

close ISSUE-7

<trackbot> ISSUE-7 User Agent Media Fragment Resolution and Processing closed

6. ISSUE-12

ISSUE-12?

<trackbot> ISSUE-12 -- What's the relationship between Images (CSS) Sprites and the spatial dimension of the Media Fragments URI scheme? -- open

<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/12

Raphael: use of the spatial dimension for highlighting region (current implementation) or cropping (sprite)

Jack: this is 2 different use cases

Yves: no, the first intent is to define a region ... and not to define what to do with it

Jack: yes, but in the temporal case, we provide more information
... perhaps in Section 7, we should write, "unlike the temporal dimension ..."
... I sugges to edit Section 7.1 to clarify this ...

<silvia> I agree

Jack: 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. "
... to state we have two use cases: 1/ highlight 2/ sprite
... done

comment ISSUE-12: the third paragraph of Section 7.1 has been updated

close ISSUE-12

<trackbot> ISSUE-12 What's the relationship between Images (CSS) Sprites and the spatial dimension of the Media Fragments URI scheme? closed

7. Section 4.1

Raphael: is the pseudo algorithm written by Philip useful?

Yves and Jack: the pseudo code is useless

Erik: +1

Jack: we are not writing workaround for existing sloppy implementations

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

<Yves> b, c

<davy> b, c

<hackerjack> b, c (in order)

b

<erik> b

Jack: new Appendix D: notes on parsing media fragment URIs
... I'm editing

<scribe> ACTION: raphael to email philip about this decision [recorded in http://www.w3.org/2010/06/16-mediafrag-minutes.html#action02]

<trackbot> Sorry, couldn't find user - raphael

<scribe> ACTION: troncy to email philip about this decision [recorded in http://www.w3.org/2010/06/16-mediafrag-minutes.html#action03]

<trackbot> Created ACTION-177 - Email philip about this decision [on Raphaël Troncy - due 2010-06-23].

close ACTION-177

<trackbot> ACTION-177 Email philip about this decision closed

Raphael: mail sent

Jack: I'm moving the editorial note of Silvia in ex 4.1.2 into Section 7 and drafting a new paragraph

8. Internaitonalization

Raphael: Yves sent an email yesterday to the i18n group
... see http://lists.w3.org/Archives/Public/public-media-fragment/2010Jun/0022.html
... I suggest to open an Issue for tracking this

ISSUE: Media Fragment track names and IRIs

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

Silvia suggested on the list to redefine the production rules in terms of rfc 3987 rather than 3986

Yves: I think it would be more difficult
... we don't know the encoding, etc.
... let's i18n fix this which touches several groups

9. ISSUE-14

ISSUE-14?

<trackbot> ISSUE-14 -- How to deal with embedded time stamps -- open

<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/14

Jack: for container-based timestamps (which may have gaps), we think there is no issue
... gaps will be preserved so to speak
... for the other case, smpte timestamps with labels ... it is almost as id
... there are many issues
... not being 0 based is one issue, but you can also have strange gaps
... unclear what a media player will do with it
... I'm adding a new sentence in the section 7.3
... "SMPTE Timecodes: "
... in order to close this issue

Room: problem regarding the units requested versus the units used in the response
... should it be enforced to be the same?
... should we say something at all about this?

Yves: we say nothing since we infer that people will use smpte time code know what they are doing

<Yves> ISSUE-14?

<trackbot> ISSUE-14 -- How to deal with embedded time stamps -- open

<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/14

close ISSUE-14

<trackbot> ISSUE-14 How to deal with embedded time stamps closed

<Yves> ISSUE-16?

<trackbot> ISSUE-16 -- Combining axis is probably not going to be done by LC, but we should write somewhere that this is doable -- open

<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/16

Davy: the biggest issue was with the spatial dimension

<Yves> issue-13?

<trackbot> ISSUE-13 -- Write a IETF draft for proposing how to register the fragment scheme for all media types -- open

<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/13

Davy: we can close it since we are doign combination now, e.g. track + time

close ISSUE-16

<trackbot> ISSUE-16 Combining axis is probably not going to be done by LC, but we should write somewhere that this is doable closed

Yves: I have discussion with larry masinter and IETF about this
... we don't need this for Last Call

<scribe> ... ongoing issue

UNKNOWN_SPEAKER: we need to figure out what would be the process, in our own spec, in a RFC, etc.

10. Last Call Resolution

<hackerjack> +1

<Yves> +1

PROPOSED: the document is good enough to be a Last Call

<davy> +1

<Yves> +1

<Wim> +1

+1

<hackerjack> +1

<erik> +1

Silvia has agreed also

no objections

<erik> s/agrees/agreed

<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

<Yves> Silvia, please review the doc (the one by end of this week)

RESOLUTION: Publish the document as a Last Call Working Draft next week

Raphael: yves will complete his actions by Sunday
... davy will have finished 176 today
... we need internal review

Erik: I suggest Silvia

<scribe> ACTION: Silvia to review the complete document, remove unnecessary editorial notes before publication [recorded in http://www.w3.org/2010/06/16-mediafrag-minutes.html#action04]

<trackbot> Created ACTION-178 - Review the complete document, remove unnecessary editorial notes before publication [on Silvia Pfeiffer - due 2010-06-23].

Raphael: we need to decide on which groups we want and wish to have reviews from
... MUST working groups: HTML WG, Media Annotations WG, SYMM, Semantic Web CG, Hypertext CG, TAG, IETF
... WISH to have additional reviews from: CSS, SVG, TimedText, I18N, Audio XG

Yves: deadline for comments?
... end of August!

11. AOB

Raphael: Media Annotations LCWD
... how do we make a group reply?
... or do we make individual replies?

Jack: I want to read this with my media fragments hat on
... discuss by email about a group reply?
... people comment on their own name
... write replies to our group when this is common issues for the MF WG

Raphael: LCWD of Media annotations: Ontology = http://www.w3.org/TR/2010/WD-mediaont-10-20100608/
... APi: http://www.w3.org/TR/2010/WD-mediaont-api-1.0-20100608/
... we provide a group reply with all the collected issues that interest the group
... we dedicate one of the upcoming telecon about this

<erik> on behalf of the chairs ... a BIG thanks to all contributors of this F2F ... LC here we come :)

Davy: section 5.1.3 now completed!

Room: reviewing ...

<erik> Thx Davy!

close ACTION-176

<trackbot> ACTION-176 Edit a new section 5.1.3 named "Server triggered redirect" that documents fully this solution closed

Frank: perhaps add in the reference section a ref to the Link Header

<davy> Added ref to the Web Linking draft

thanks davy

Meeting successful

[adjourned]

Summary of Action Items

[NEW] ACTION: Davy to edit a new section 5.1.3 named "Server triggered redirect" that documents fully this solution [recorded in http://www.w3.org/2010/06/16-mediafrag-minutes.html#action01]
[NEW] ACTION: raphael to email philip about this decision [recorded in http://www.w3.org/2010/06/16-mediafrag-minutes.html#action02]
[NEW] ACTION: Silvia to review the complete document, remove unnecessary editorial notes before publication [recorded in http://www.w3.org/2010/06/16-mediafrag-minutes.html#action04]
[NEW] ACTION: troncy to email philip about this decision [recorded in http://www.w3.org/2010/06/16-mediafrag-minutes.html#action03]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.135 (CVS log)
$Date: 2010/06/16 14:35:45 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
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/corect/sorrect/
Succeeded: s/=/+/
Succeeded: s/-1/+1/
Succeeded: s/Embedded/SMPTE/
Succeeded: s/agrees/agreed/
FAILED: s/agrees/agreed/
Succeeded: s/p//
Found Scribe: jack
WARNING: No scribe lines found matching ScribeNick pattern: <jack> ...
Found ScribeNick: hackerjack
Found ScribeNick: raphael
Found ScribeNick: raphael
ScribeNicks: hackerjack, raphael
Default Present: Meeting_Room, silvia
Present: Jack Yves Rapha�l Erik Davy Wim Frank
Regrets: Michael
Agenda: http://www.w3.org/2008/WebVideo/Fragments/wiki/SixthF2FAgenda
Found Date: 16 Jun 2010
Guessing minutes URL: http://www.w3.org/2010/06/16-mediafrag-minutes.html
People with action items: davy raphael silvia troncy

[End of scribe.perl diagnostic output]