You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1004 lines
38 KiB
1004 lines
38 KiB
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
|
|
<html lang='en' xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
|
|
<head>
|
|
<meta name="generator" content=
|
|
"HTML Tidy for Linux (vers 6 November 2007), see www.w3.org" />
|
|
|
|
<title>Media Fragments Working Group Teleconference -- 16 Jun
|
|
2010</title>
|
|
<link type="text/css" rel="STYLESHEET" href=
|
|
"http://www.w3.org/StyleSheets/base.css" />
|
|
<link type="text/css" rel="STYLESHEET" href=
|
|
"http://www.w3.org/StyleSheets/public.css" />
|
|
<link type="text/css" rel="STYLESHEET" href=
|
|
"http://www.w3.org/2004/02/minutes-style.css" />
|
|
<meta content="Media Fragments Working Group Teleconference"
|
|
name="Title" />
|
|
<meta content="text/html; charset=utf-8" http-equiv=
|
|
"Content-Type" />
|
|
</head>
|
|
|
|
<body>
|
|
<p><a href="http://www.w3.org/"><img src=
|
|
"http://www.w3.org/Icons/w3c_home" alt="W3C" border="0" height=
|
|
"48" width="72" /></a></p>
|
|
|
|
<h1>- DRAFT -</h1>
|
|
|
|
<h1>Media Fragments Working Group Teleconference</h1>
|
|
|
|
<h2>16 Jun 2010</h2>
|
|
|
|
<p><a href=
|
|
'http://www.w3.org/2008/WebVideo/Fragments/wiki/SixthF2FAgenda'>Agenda</a></p>
|
|
|
|
<p>See also: <a href=
|
|
"http://www.w3.org/2010/06/16-mediafrag-irc">IRC log</a></p>
|
|
|
|
<h2><a name="attendees" id="attendees">Attendees</a></h2>
|
|
|
|
<div class="intro">
|
|
<dl>
|
|
<dt>Present</dt>
|
|
|
|
<dd>Jack, Yves, Rapha�l, Erik, Davy, Wim, Frank</dd>
|
|
|
|
<dt>Regrets</dt>
|
|
|
|
<dd>Michael</dd>
|
|
|
|
<dt>Chair</dt>
|
|
|
|
<dd>Erik, Rapha�l</dd>
|
|
|
|
<dt>Scribe</dt>
|
|
|
|
<dd>jack</dd>
|
|
</dl>
|
|
</div>
|
|
|
|
<h2>Contents</h2>
|
|
|
|
<ul>
|
|
<li>
|
|
<a href="#agenda">Topics</a>
|
|
|
|
<ol>
|
|
<li><a href="#item01">1. Protocol Handling (cont.)</a></li>
|
|
|
|
<li><a href="#item02">2. ISSUE-4: Discovery of Track and
|
|
Named fragments</a></li>
|
|
|
|
<li><a href="#item03">3. ISSUE-5</a></li>
|
|
|
|
<li><a href="#item04">4. ISSUE-6</a></li>
|
|
|
|
<li><a href="#item05">5. ISSUE-7</a></li>
|
|
|
|
<li><a href="#item06">6. ISSUE-12</a></li>
|
|
|
|
<li><a href="#item07">7. Section 4.1</a></li>
|
|
|
|
<li><a href="#item08">8. Internaitonalization</a></li>
|
|
|
|
<li><a href="#item09">9. ISSUE-14</a></li>
|
|
|
|
<li><a href="#item10">10. Last Call Resolution</a></li>
|
|
|
|
<li><a href="#item11">11. AOB</a></li>
|
|
</ol>
|
|
</li>
|
|
|
|
<li><a href="#ActionSummary">Summary of Action Items</a></li>
|
|
</ul>
|
|
<hr />
|
|
|
|
<div class="meeting">
|
|
<p class='phone'></p>
|
|
|
|
<p class='phone'></p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Date: 16 June
|
|
2010</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> SCribe: jack</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> ScribeNick:
|
|
hackerjack</p>
|
|
|
|
<p class='irc'><<cite>scribe</cite>> agenda: <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/wiki/SixthF2FAgenda">
|
|
http://www.w3.org/2008/WebVideo/Fragments/wiki/SixthF2FAgenda</a></p>
|
|
|
|
<p class='irc'><<cite>scribe</cite>> agenda: <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/wiki/SixthF2FAgenda">
|
|
http://www.w3.org/2008/WebVideo/Fragments/wiki/SixthF2FAgenda</a></p>
|
|
|
|
<p class='phone'>trackbot start teleconf</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> About Silvia's mail of
|
|
yesterday: BNF is incomplete when only the "include-setup" is
|
|
returned.</p>
|
|
|
|
<p class='phone'><cite>All:</cite> agree. Yves to fix it
|
|
now.</p>
|
|
|
|
<h3 id="item01">1. Protocol Handling (cont.)</h3>
|
|
|
|
<p class='phone'><cite>Erik:</cite> Let's revisit the redirect
|
|
idea for track and id we discussed yesterday.<br />
|
|
... for id it seems to be a good idea, but for track we could
|
|
go both ways (redirect or direct implementation)</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> Room: discussing
|
|
again the pro/cons of the track + id handling</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> ... track is now
|
|
handled as ID, and not as time</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> ... the redirect to
|
|
query is a fallback solution just because the proble is that we
|
|
will have too many characters in HTTP headers</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> Raphael: should we
|
|
document two solutions for handling track ... one using the
|
|
redirect and another one similar to time?</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> Jack: well, in this
|
|
case, we are re-introducing the problem for caching cascading
|
|
projections</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> Erik: the only
|
|
cascading problem will be track + time</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> Jack: rationale, if
|
|
we go the redirect way, the spec is finished today, and we can
|
|
take it out</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> ... if we go with
|
|
Davy's solution, then more work is needed, we do not know how
|
|
cache will behave</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> Jack: most of the
|
|
use cases will be time selection, some will be track selection,
|
|
combination will be even rarer</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> Jack: how robust is
|
|
our current text for caching tracks? We need more
|
|
implementation experience</p>
|
|
|
|
<p class='phone'><cite>All:</cite> discussion about
|
|
cacheability (by classic caches) of multipart</p>
|
|
|
|
<p class='phone'><cite>Erik:</cite> maybe we shoulnd't worry
|
|
too much about old-style caches: there will be a strong push
|
|
towards mf-aware (once mf is popular)</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> Discussing:
|
|
<a href="http://www.w3.org/2010/06/15-mediafrag-minutes.html#item06">
|
|
http://www.w3.org/2010/06/15-mediafrag-minutes.html#item06</a></p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> explaining the issues of
|
|
yesterday and this morning to Silvia, and sketching tradeoffs
|
|
(elegance versus quick publishing)</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> we shouldn't worry
|
|
overmuch about cache implementation in our LC spec. We need
|
|
implementations before we can be<br />
|
|
... sure our text is sorrect.<br />
|
|
... issue with redirect, specifically with redirect leading to
|
|
new resource.</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> but client knows about the
|
|
linking to the old one.</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> that is a hack.</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> 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</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> … so, getting back
|
|
to the original resource and its tracks may be impossible</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> … also, I am not too
|
|
worried about these things yet, because I would wait and see
|
|
what browser vendors implement</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> … it is good for us
|
|
to identify these issues, but I'm not sure we can solve them
|
|
fully</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> .. without
|
|
implementations we won't have the answer to everything now</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> … for #track, I
|
|
would offer both options to browser vendors, then see how they
|
|
go ;)</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> OK Silvia</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> we plan to enforce
|
|
also the use of a Link header ... so context towards the
|
|
original resource is here!</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> Silvia: <a href=
|
|
"http://www.web-polygraph.org/docs/userman/ranges.html">http://www.web-polygraph.org/docs/userman/ranges.html</a>
|
|
<- looks like it supports multiple byte ranges</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> Silvia: but that
|
|
might be a server and not a proxy...</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> 5.2 has the
|
|
following paragraph:</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> 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.</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> 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</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> ok</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> second,<br />
|
|
... we make sure that the spec correctly specifies fragmenting
|
|
of tracks<br />
|
|
... third, similar for ID</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I think a web
|
|
browser has actually 3 options:</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> … 1. use byte
|
|
ranges</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> … 2. use
|
|
redirect</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> … 3. do locally</p>
|
|
|
|
<p class='phone'>silvia, you dropped from the audio</p>
|
|
|
|
<p class='phone'><cite>All:</cite> discussion about whether
|
|
lots of small fragments will work for the clients anyway.</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> talked to browser
|
|
vendors, they will probably get whole resourcce, because their
|
|
decoders may not handle it</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> scribenick:
|
|
raphael</p>
|
|
|
|
<p class='phone'><cite>Summary:</cite> for the 3 dimensions,
|
|
time, track and id, they will be a double mechanism described
|
|
in the protocol<br />
|
|
... either a direct way as it is described in the spec<br />
|
|
... or as a redirect (30x reply) pointing to the same request
|
|
that replace the # by the ?<br />
|
|
... the second server reply MAY or MUST? contain a Link header
|
|
pointing to the original resource the new one is derived
|
|
from</p>
|
|
|
|
<p class='phone'><cite>PROPOSED:</cite> 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</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> proposed headline for new
|
|
section 5.1.3 = Server triggered redirect</p>
|
|
|
|
<p class='irc'><<cite>hackerjack</cite>> Davy: but there
|
|
is another issue with a redirect. The server has no way to
|
|
communicate to the client whether the returned new resource</p>
|
|
|
|
<p class='irc'><<cite>hackerjack</cite>> ... has the mf
|
|
completely applied or not. In the latter case the client would
|
|
still have work to do.</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> issue with the
|
|
redirect is fragment handling on the redirected resource</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> <a href=
|
|
"http://tools.ietf.org/html/draft-nottingham-http-link-header+10">
|
|
http://tools.ietf.org/html/draft-nottingham-http-link-header+10</a></p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> 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?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> it's an actual HTTP
|
|
redirect, right?</p>
|
|
|
|
<p class='phone'>Yes, it is a real redirect</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> the issue is: imagine
|
|
that the UA has just requested a track (#track=audio4)<br />
|
|
... the server cannot extract the track, but send a 307
|
|
pointing to the full resource<br />
|
|
... how the UA knows whether the redirects points to the track
|
|
it has originally requested or to the full resource?<br />
|
|
... Ninsuna proxy currently works like this, send a redirecto
|
|
to the full resource when it cannot extract the fragments</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> but ours has a link
|
|
header?</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> idea would be to add a
|
|
link header in the 307 reply to convey this information</p>
|
|
|
|
<p class='phone'>I'm talking of the first reply, the 307, not
|
|
the second one with the actual data which has a Link header</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> for the second reply, I
|
|
suggest we use the property named 'alternate'<br />
|
|
... so syntax would be:</p>
|
|
|
|
<p class='phone'><cite>Link:</cite> <<a href=
|
|
"http://www.example.com/video.ogg#track=audio4%3E">http://www.example.com/video.ogg#track=audio4></a>
|
|
alternate</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> perhaps we should use
|
|
another term, it seems to me a hack<br />
|
|
... no, I fully agree now, Yves convinced me</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> for the first reply, the
|
|
307, we need a new term<br />
|
|
... e.g. fragment<br />
|
|
... so syntax would be:</p>
|
|
|
|
<p class='phone'><cite>Link:</cite> <<a href=
|
|
"http://www.example.com/video.ogg#track=audio4%3E">http://www.example.com/video.ogg#track=audio4></a>
|
|
fragment</p>
|
|
|
|
<p class='phone'><cite>Location:</cite> <a href=
|
|
"http://www.example.com/video.ogv">http://www.example.com/video.ogv</a><br />
|
|
|
|
... <a href=
|
|
"http://www.example.com/video.ogv?track=audio4">http://www.example.com/video.ogv?track=audio4</a></p>
|
|
|
|
<p class='phone'><cite>Vary:</cite> *<br />
|
|
... in order to not cache the 307 reply</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> the description of how
|
|
it works should now be completed, back to the proposal</p>
|
|
|
|
<p class='phone'><cite>PROPOSED:</cite> 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</p>
|
|
|
|
<p class='phone'>let's vote</p>
|
|
|
|
<p class='irc'><<cite>hackerjack</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>Wim</cite>> +1</p>
|
|
|
|
<p class='phone'>+1</p>
|
|
|
|
<p class='irc'><<cite>erik</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>hackerjack</cite>> rrsagent draft
|
|
minutes</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> +1</p>
|
|
|
|
<p class='phone'><strong class='resolution'>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</strong></p><a name="action01" id="action01"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> Davy to edit a new section 5.1.3 named
|
|
"Server triggered redirect" that documents fully this solution
|
|
[recorded in <a href=
|
|
"http://www.w3.org/2010/06/16-mediafrag-minutes.html#action01">http://www.w3.org/2010/06/16-mediafrag-minutes.html#action01</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> 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].</p>
|
|
|
|
<p class='irc'><<cite>hackerjack</cite>> 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.</p>
|
|
|
|
<p class='irc'><<cite>hackerjack</cite>> Raphael: let's
|
|
drop test cases, not important for LC</p>
|
|
|
|
<p class='irc'><<cite>hackerjack</cite>> Raphael:
|
|
proposal: we allow for a testcase f2f in september, if
|
|
needed.</p>
|
|
|
|
<p class='irc'><<cite>hackerjack</cite>> Raphael:
|
|
proposal: after lunch we do the "wednesday morning agenda".</p>
|
|
|
|
<p class='phone'>[lunch break]</p>
|
|
|
|
<p class='irc'><<cite>scribe</cite>> scribenick:
|
|
raphael</p>
|
|
|
|
<h3 id="item02">2. ISSUE-4: Discovery of Track and Named
|
|
fragments</h3>
|
|
|
|
<p class='phone'>ISSUE-4?</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ISSUE-4 -- Should
|
|
we pre-define some track names? -- open</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/4">http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/4</a></p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> <a href=
|
|
"http://www.w3.org/WAI/PF/HTML/wiki/Media_MultitrackAPI">http://www.w3.org/WAI/PF/HTML/wiki/Media_MultitrackAPI</a><br />
|
|
|
|
... how do we know which tracks are available for
|
|
selection<br />
|
|
... could be extended to, how do we know which id/names are
|
|
available for selection</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> why do we care?<br />
|
|
... our task is to enable the construction of the selection and
|
|
the protocol handling<br />
|
|
... how the discovery is performed does not matter too us</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> all what we are saying is
|
|
that track names are UTF-8 strings</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> 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</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> 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<br />
|
|
... but we mention the existing discovery mechanism such as
|
|
ROE, Media Annotations, HTML5 MediaMultiTrack API</p>
|
|
|
|
<p class='phone'><cite>Davy:</cite> I'm editing the spec right
|
|
now</p>
|
|
|
|
<p class='irc'><<cite>hackerjack</cite>> Raphael: ok, all
|
|
agreed, Davy will fix the text</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> can we close this
|
|
issue?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> yes, please</p>
|
|
|
|
<p class='phone'>comment ISSUE-4 track names discovery is
|
|
handled by others and we list example techniques</p>
|
|
|
|
<p class='phone'>close ISSUE-4</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ISSUE-4 Should we
|
|
pre-define some track names? closed</p>
|
|
|
|
<h3 id="item03">3. ISSUE-5</h3>
|
|
|
|
<p class='phone'>ISSUE-5?</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ISSUE-5 --
|
|
Handling spatial cropping requires information at client-side
|
|
-- open</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/5">http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/5</a></p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> is this clear that in
|
|
the case of the spatial dimension, nothing is sent to the
|
|
server?</p>
|
|
|
|
<p class='phone'><cite>Davy:</cite> yes<br />
|
|
... in 5.1.2<br />
|
|
... 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.</p>
|
|
|
|
<p class='phone'>comment ISSUE-5 not relevant anymore</p>
|
|
|
|
<p class='phone'>close ISSUE-5</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ISSUE-5 Handling
|
|
spatial cropping requires information at client-side closed</p>
|
|
|
|
<h3 id="item04">4. ISSUE-6</h3>
|
|
|
|
<p class='phone'>ISSUE-6?</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ISSUE-6 --
|
|
Temporal clips that require transcoding -- open</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/6">http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/6</a></p>
|
|
|
|
<p class='phone'><cite>Erik:</cite> The section 3.1 is crystal
|
|
clear<br />
|
|
... 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.<br />
|
|
... that closes the ISSUE<br />
|
|
... editor note needs to be removed?<br />
|
|
... link towards the UC doc needs to be modified<br />
|
|
... no link to fix</p>
|
|
|
|
<p class='phone'><cite>Davy:</cite> ed note removed</p>
|
|
|
|
<p class='phone'>close ISSUE-6</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ISSUE-6 Temporal
|
|
clips that require transcoding closed</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> references are ugly, need
|
|
to fix this</p>
|
|
|
|
<p class='irc'><<cite>hackerjack</cite>> Jack: Issue is:
|
|
unmatch <a> element in the references, but xhtml
|
|
document.</p>
|
|
|
|
<h3 id="item05">5. ISSUE-7</h3>
|
|
|
|
<p class='phone'>ISSUE-7?</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ISSUE-7 -- User
|
|
Agent Media Fragment Resolution and Processing -- open</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/7">http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/7</a></p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> this is the protocol
|
|
description<br />
|
|
... this is now done!</p>
|
|
|
|
<p class='phone'>comment ISSUE-7 This is the protocol
|
|
description now nicely described</p>
|
|
|
|
<p class='phone'>close ISSUE-7</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ISSUE-7 User Agent
|
|
Media Fragment Resolution and Processing closed</p>
|
|
|
|
<h3 id="item06">6. ISSUE-12</h3>
|
|
|
|
<p class='phone'>ISSUE-12?</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ISSUE-12 -- What's
|
|
the relationship between Images (CSS) Sprites and the spatial
|
|
dimension of the Media Fragments URI scheme? -- open</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/12">http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/12</a></p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> use of the spatial
|
|
dimension for highlighting region (current implementation) or
|
|
cropping (sprite)</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> this is 2 different use
|
|
cases</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> no, the first intent is to
|
|
define a region ... and not to define what to do with it</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> yes, but in the temporal
|
|
case, we provide more information<br />
|
|
... perhaps in Section 7, we should write, "unlike the temporal
|
|
dimension ..."<br />
|
|
... I sugges to edit Section 7.1 to clarify this ...</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I agree</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> 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. "<br />
|
|
... to state we have two use cases: 1/ highlight 2/
|
|
sprite<br />
|
|
... done</p>
|
|
|
|
<p class='phone'>comment ISSUE-12: the third paragraph of
|
|
Section 7.1 has been updated</p>
|
|
|
|
<p class='phone'>close ISSUE-12</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ISSUE-12 What's
|
|
the relationship between Images (CSS) Sprites and the spatial
|
|
dimension of the Media Fragments URI scheme? closed</p>
|
|
|
|
<h3 id="item07">7. Section 4.1</h3>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> is the pseudo algorithm
|
|
written by Philip useful?</p>
|
|
|
|
<p class='phone'>Yves and Jack: the pseudo code is useless</p>
|
|
|
|
<p class='phone'><cite>Erik:</cite> +1</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> we are not writing
|
|
workaround for existing sloppy implementations</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> 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</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> b, c</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> b, c</p>
|
|
|
|
<p class='irc'><<cite>hackerjack</cite>> b, c (in
|
|
order)</p>
|
|
|
|
<p class='phone'>b</p>
|
|
|
|
<p class='irc'><<cite>erik</cite>> b</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> new Appendix D: notes on
|
|
parsing media fragment URIs<br />
|
|
... I'm editing</p><a name="action02" id="action02"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> raphael to email philip about this
|
|
decision [recorded in <a href=
|
|
"http://www.w3.org/2010/06/16-mediafrag-minutes.html#action02">http://www.w3.org/2010/06/16-mediafrag-minutes.html#action02</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Sorry, couldn't
|
|
find user - raphael</p><a name="action03" id="action03"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> troncy to email philip about this
|
|
decision [recorded in <a href=
|
|
"http://www.w3.org/2010/06/16-mediafrag-minutes.html#action03">http://www.w3.org/2010/06/16-mediafrag-minutes.html#action03</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ACTION-177
|
|
- Email philip about this decision [on Raphaël Troncy - due
|
|
2010-06-23].</p>
|
|
|
|
<p class='phone'>close ACTION-177</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-177 Email
|
|
philip about this decision closed</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> mail sent</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> I'm moving the editorial
|
|
note of Silvia in ex 4.1.2 into Section 7 and drafting a new
|
|
paragraph</p>
|
|
|
|
<h3 id="item08">8. Internaitonalization</h3>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> Yves sent an email
|
|
yesterday to the i18n group<br />
|
|
... see <a href=
|
|
"http://lists.w3.org/Archives/Public/public-media-fragment/2010Jun/0022.html">
|
|
http://lists.w3.org/Archives/Public/public-media-fragment/2010Jun/0022.html</a><br />
|
|
|
|
... I suggest to open an Issue for tracking this</p>
|
|
|
|
<p class='phone'><cite>ISSUE:</cite> Media Fragment track names
|
|
and IRIs</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ISSUE-17 -
|
|
Media Fragment track names and IRIs ; please complete
|
|
additional details at <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/17/edit">
|
|
http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/17/edit</a>
|
|
.</p>
|
|
|
|
<p class='phone'>Silvia suggested on the list to redefine the
|
|
production rules in terms of rfc 3987 rather than 3986</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> I think it would be more
|
|
difficult<br />
|
|
... we don't know the encoding, etc.<br />
|
|
... let's i18n fix this which touches several groups</p>
|
|
|
|
<h3 id="item09">9. ISSUE-14</h3>
|
|
|
|
<p class='phone'>ISSUE-14?</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ISSUE-14 -- How to
|
|
deal with embedded time stamps -- open</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/14">http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/14</a></p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> for container-based
|
|
timestamps (which may have gaps), we think there is no
|
|
issue<br />
|
|
... gaps will be preserved so to speak<br />
|
|
... for the other case, smpte timestamps with labels ... it is
|
|
almost as id<br />
|
|
... there are many issues<br />
|
|
... not being 0 based is one issue, but you can also have
|
|
strange gaps<br />
|
|
... unclear what a media player will do with it<br />
|
|
... I'm adding a new sentence in the section 7.3<br />
|
|
... "SMPTE Timecodes: "<br />
|
|
... in order to close this issue</p>
|
|
|
|
<p class='phone'><cite>Room:</cite> problem regarding the units
|
|
requested versus the units used in the response<br />
|
|
... should it be enforced to be the same?<br />
|
|
... should we say something at all about this?</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> we say nothing since we
|
|
infer that people will use smpte time code know what they are
|
|
doing</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> ISSUE-14?</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ISSUE-14 -- How to
|
|
deal with embedded time stamps -- open</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/14">http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/14</a></p>
|
|
|
|
<p class='phone'>close ISSUE-14</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ISSUE-14 How to
|
|
deal with embedded time stamps closed</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> ISSUE-16?</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ISSUE-16 --
|
|
Combining axis is probably not going to be done by LC, but we
|
|
should write somewhere that this is doable -- open</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/16">http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/16</a></p>
|
|
|
|
<p class='phone'><cite>Davy:</cite> the biggest issue was with
|
|
the spatial dimension</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> issue-13?</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ISSUE-13 -- Write
|
|
a IETF draft for proposing how to register the fragment scheme
|
|
for all media types -- open</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/13">http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/13</a></p>
|
|
|
|
<p class='phone'><cite>Davy:</cite> we can close it since we
|
|
are doign combination now, e.g. track + time</p>
|
|
|
|
<p class='phone'>close ISSUE-16</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ISSUE-16 Combining
|
|
axis is probably not going to be done by LC, but we should
|
|
write somewhere that this is doable closed</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> I have discussion with
|
|
larry masinter and IETF about this<br />
|
|
... we don't need this for Last Call</p>
|
|
|
|
<p class='irc'><<cite>scribe</cite>> ... ongoing
|
|
issue</p>
|
|
|
|
<p class='phone'><cite>UNKNOWN_SPEAKER:</cite> we need to
|
|
figure out what would be the process, in our own spec, in a
|
|
RFC, etc.</p>
|
|
|
|
<h3 id="item10">10. Last Call Resolution</h3>
|
|
|
|
<p class='irc'><<cite>hackerjack</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> +1</p>
|
|
|
|
<p class='phone'><cite>PROPOSED:</cite> the document is good
|
|
enough to be a Last Call</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>Wim</cite>> +1</p>
|
|
|
|
<p class='phone'>+1</p>
|
|
|
|
<p class='irc'><<cite>hackerjack</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>erik</cite>> +1</p>
|
|
|
|
<p class='phone'>Silvia has agreed also</p>
|
|
|
|
<p class='phone'>no objections</p>
|
|
|
|
<p class='irc'><<cite>erik</cite>> s/agrees/agreed</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> see <a href=
|
|
"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">
|
|
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</a></p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> Silvia, please review
|
|
the doc (the one by end of this week)</p>
|
|
|
|
<p class='phone'><strong class='resolution'>RESOLUTION: Publish
|
|
the document as a Last Call Working Draft next
|
|
week</strong></p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> yves will complete his
|
|
actions by Sunday<br />
|
|
... davy will have finished 176 today<br />
|
|
... we need internal review</p>
|
|
|
|
<p class='phone'><cite>Erik:</cite> I suggest
|
|
Silvia</p><a name="action04" id="action04"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> Silvia to review the complete
|
|
document, remove unnecessary editorial notes before publication
|
|
[recorded in <a href=
|
|
"http://www.w3.org/2010/06/16-mediafrag-minutes.html#action04">http://www.w3.org/2010/06/16-mediafrag-minutes.html#action04</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ACTION-178
|
|
- Review the complete document, remove unnecessary editorial
|
|
notes before publication [on Silvia Pfeiffer - due
|
|
2010-06-23].</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> we need to decide on
|
|
which groups we want and wish to have reviews from<br />
|
|
... MUST working groups: HTML WG, Media Annotations WG, SYMM,
|
|
Semantic Web CG, Hypertext CG, TAG, IETF<br />
|
|
... WISH to have additional reviews from: CSS, SVG, TimedText,
|
|
I18N, Audio XG</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> deadline for
|
|
comments?<br />
|
|
... end of August!</p>
|
|
|
|
<h3 id="item11">11. AOB</h3>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> Media Annotations
|
|
LCWD<br />
|
|
... how do we make a group reply?<br />
|
|
... or do we make individual replies?</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> I want to read this with my
|
|
media fragments hat on<br />
|
|
... discuss by email about a group reply?<br />
|
|
... people comment on their own name<br />
|
|
... write replies to our group when this is common issues for
|
|
the MF WG</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> LCWD of Media
|
|
annotations: Ontology = <a href=
|
|
"http://www.w3.org/TR/2010/WD-mediaont-10-20100608/">http://www.w3.org/TR/2010/WD-mediaont-10-20100608/</a><br />
|
|
|
|
... APi: <a href=
|
|
"http://www.w3.org/TR/2010/WD-mediaont-api-1.0-20100608/">http://www.w3.org/TR/2010/WD-mediaont-api-1.0-20100608/</a><br />
|
|
|
|
... we provide a group reply with all the collected issues that
|
|
interest the group<br />
|
|
... we dedicate one of the upcoming telecon about this</p>
|
|
|
|
<p class='irc'><<cite>erik</cite>> on behalf of the
|
|
chairs ... a BIG thanks to all contributors of this F2F ... LC
|
|
here we come :)</p>
|
|
|
|
<p class='phone'><cite>Davy:</cite> section 5.1.3 now
|
|
completed!</p>
|
|
|
|
<p class='phone'><cite>Room:</cite> reviewing ...</p>
|
|
|
|
<p class='irc'><<cite>erik</cite>> Thx Davy!</p>
|
|
|
|
<p class='phone'>close ACTION-176</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> ACTION-176 Edit a
|
|
new section 5.1.3 named "Server triggered redirect" that
|
|
documents fully this solution closed</p>
|
|
|
|
<p class='phone'><cite>Frank:</cite> perhaps add in the
|
|
reference section a ref to the Link Header</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> Added ref to the Web
|
|
Linking draft</p>
|
|
|
|
<p class='phone'>thanks davy</p>
|
|
|
|
<p class='phone'>Meeting successful</p>
|
|
|
|
<p class='phone'>[adjourned]</p>
|
|
</div>
|
|
|
|
<h2><a name="ActionSummary" id="ActionSummary">Summary of Action
|
|
Items</a></h2><!-- Action Items -->
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> Davy to edit a
|
|
new section 5.1.3 named "Server triggered redirect" that
|
|
documents fully this solution [recorded in <a href=
|
|
"http://www.w3.org/2010/06/16-mediafrag-minutes.html#action01">http://www.w3.org/2010/06/16-mediafrag-minutes.html#action01</a>]<br />
|
|
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> raphael to email
|
|
philip about this decision [recorded in <a href=
|
|
"http://www.w3.org/2010/06/16-mediafrag-minutes.html#action02">http://www.w3.org/2010/06/16-mediafrag-minutes.html#action02</a>]<br />
|
|
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> Silvia to review
|
|
the complete document, remove unnecessary editorial notes before
|
|
publication [recorded in <a href=
|
|
"http://www.w3.org/2010/06/16-mediafrag-minutes.html#action04">http://www.w3.org/2010/06/16-mediafrag-minutes.html#action04</a>]<br />
|
|
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> troncy to email
|
|
philip about this decision [recorded in <a href=
|
|
"http://www.w3.org/2010/06/16-mediafrag-minutes.html#action03">http://www.w3.org/2010/06/16-mediafrag-minutes.html#action03</a>]<br />
|
|
|
|
<br />
|
|
[End of minutes]<br />
|
|
<hr />
|
|
|
|
<address>
|
|
Minutes formatted by David Booth's <a href=
|
|
"http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm">
|
|
scribe.perl</a> version 1.135 (<a href=
|
|
"http://dev.w3.org/cvsweb/2002/scribe/">CVS log</a>)<br />
|
|
$Date: 2010/06/16 14:35:45 $
|
|
</address>
|
|
|
|
<div class="diagnostics">
|
|
<hr />
|
|
|
|
<h2>Scribe.perl diagnostic output</h2>[Delete this section
|
|
before finalizing the minutes.]<br />
|
|
<pre>
|
|
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20
|
|
Check for newer version at <a href=
|
|
"http://dev.w3.org/cvsweb/~checkout~/2002/scribe/">http://dev.w3.org/cvsweb/~checkout~/2002/scribe/</a>
|
|
|
|
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: <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/wiki/SixthF2FAgenda">http://www.w3.org/2008/WebVideo/Fragments/wiki/SixthF2FAgenda</a>
|
|
Found Date: 16 Jun 2010
|
|
Guessing minutes URL: <a href=
|
|
"http://www.w3.org/2010/06/16-mediafrag-minutes.html">http://www.w3.org/2010/06/16-mediafrag-minutes.html</a>
|
|
People with action items: davy raphael silvia troncy
|
|
|
|
</pre>[End of <a href=
|
|
"http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm">
|
|
scribe.perl</a> diagnostic output]
|
|
</div>
|
|
</body>
|
|
</html>
|