16-mediafrag-minutes.html 37.5 KB

Raw Blame History Permalink

<!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'>&lt;<cite>trackbot</cite>&gt; Date: 16 June
    2010</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; SCribe: jack</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; ScribeNick:
    hackerjack</p>

    <p class='irc'>&lt;<cite>scribe</cite>&gt; 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'>&lt;<cite>scribe</cite>&gt; 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'>&lt;<cite>raphael</cite>&gt; Room: discussing
    again the pro/cons of the track + id handling</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; ... track is now
    handled as ID, and not as time</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; ... 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'>&lt;<cite>raphael</cite>&gt; Raphael: should we
    document two solutions for handling track ... one using the
    redirect and another one similar to time?</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; Jack: well, in this
    case, we are re-introducing the problem for caching cascading
    projections</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; Erik: the only
    cascading problem will be track + time</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; Jack: rationale, if
    we go the redirect way, the spec is finished today, and we can
    take it out</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; ... if we go with
    Davy's solution, then more work is needed, we do not know how
    cache will behave</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; Jack: most of the
    use cases will be time selection, some will be track selection,
    combination will be even rarer</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; 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'>&lt;<cite>raphael</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; … so, getting back
    to the original resource and its tracks may be impossible</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; … also, I am not too
    worried about these things yet, because I would wait and see
    what browser vendors implement</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; … it is good for us
    to identify these issues, but I'm not sure we can solve them
    fully</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; .. without
    implementations we won't have the answer to everything now</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; … for #track, I
    would offer both options to browser vendors, then see how they
    go ;)</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; OK Silvia</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; we plan to enforce
    also the use of a Link header ... so context towards the
    original resource is here!</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; Silvia: <a href=
    "http://www.web-polygraph.org/docs/userman/ranges.html">http://www.web-polygraph.org/docs/userman/ranges.html</a>
    &lt;- looks like it supports multiple byte ranges</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; Silvia: but that
    might be a server and not a proxy...</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 5.2 has the
    following paragraph:</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; I think a web
    browser has actually 3 options:</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; … 1. use byte
    ranges</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; … 2. use
    redirect</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; … 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'>&lt;<cite>raphael</cite>&gt; 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'>&lt;<cite>hackerjack</cite>&gt; 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'>&lt;<cite>hackerjack</cite>&gt; ... has the mf
    completely applied or not. In the latter case the client would
    still have work to do.</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; issue with the
    redirect is fragment handling on the redirected resource</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; <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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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> &lt;<a href=
    "http://www.example.com/video.ogg#track=audio4%3E">http://www.example.com/video.ogg#track=audio4&gt;</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> &lt;<a href=
    "http://www.example.com/video.ogg#track=audio4%3E">http://www.example.com/video.ogg#track=audio4&gt;</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'>&lt;<cite>hackerjack</cite>&gt; +1</p>

    <p class='irc'>&lt;<cite>davy</cite>&gt; +1</p>

    <p class='irc'>&lt;<cite>Wim</cite>&gt; +1</p>

    <p class='phone'>+1</p>

    <p class='irc'>&lt;<cite>erik</cite>&gt; +1</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; +1</p>

    <p class='irc'>&lt;<cite>hackerjack</cite>&gt; rrsagent draft
    minutes</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; +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'>&lt;<cite>scribe</cite>&gt;
    <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'>&lt;<cite>trackbot</cite>&gt; 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'>&lt;<cite>hackerjack</cite>&gt; 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'>&lt;<cite>hackerjack</cite>&gt; Raphael: let's
    drop test cases, not important for LC</p>

    <p class='irc'>&lt;<cite>hackerjack</cite>&gt; Raphael:
    proposal: we allow for a testcase f2f in september, if
    needed.</p>

    <p class='irc'>&lt;<cite>hackerjack</cite>&gt; Raphael:
    proposal: after lunch we do the "wednesday morning agenda".</p>

    <p class='phone'>[lunch break]</p>

    <p class='irc'>&lt;<cite>scribe</cite>&gt; 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'>&lt;<cite>trackbot</cite>&gt; ISSUE-4 -- Should
    we pre-define some track names? -- open</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; <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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>hackerjack</cite>&gt; 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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>trackbot</cite>&gt; 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'>&lt;<cite>trackbot</cite>&gt; ISSUE-5 --
    Handling spatial cropping requires information at client-side
    -- open</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; <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'>&lt;<cite>trackbot</cite>&gt; 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'>&lt;<cite>trackbot</cite>&gt; ISSUE-6 --
    Temporal clips that require transcoding -- open</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; <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'>&lt;<cite>trackbot</cite>&gt; 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'>&lt;<cite>hackerjack</cite>&gt; Jack: Issue is:
    unmatch &lt;a&gt; element in the references, but xhtml
    document.</p>

    <h3 id="item05">5. ISSUE-7</h3>

    <p class='phone'>ISSUE-7?</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; ISSUE-7 -- User
    Agent Media Fragment Resolution and Processing -- open</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; <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'>&lt;<cite>trackbot</cite>&gt; 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'>&lt;<cite>trackbot</cite>&gt; 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'>&lt;<cite>trackbot</cite>&gt; <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'>&lt;<cite>silvia</cite>&gt; 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'>&lt;<cite>trackbot</cite>&gt; 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'>&lt;<cite>Yves</cite>&gt; b, c</p>

    <p class='irc'>&lt;<cite>davy</cite>&gt; b, c</p>

    <p class='irc'>&lt;<cite>hackerjack</cite>&gt; b, c (in
    order)</p>

    <p class='phone'>b</p>

    <p class='irc'>&lt;<cite>erik</cite>&gt; 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'>&lt;<cite>scribe</cite>&gt;
    <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'>&lt;<cite>trackbot</cite>&gt; Sorry, couldn't
    find user - raphael</p><a name="action03" id="action03"></a>

    <p class='irc'>&lt;<cite>scribe</cite>&gt;
    <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'>&lt;<cite>trackbot</cite>&gt; 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'>&lt;<cite>trackbot</cite>&gt; 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'>&lt;<cite>trackbot</cite>&gt; 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'>&lt;<cite>trackbot</cite>&gt; ISSUE-14 -- How to
    deal with embedded time stamps -- open</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; <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'>&lt;<cite>Yves</cite>&gt; ISSUE-14?</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; ISSUE-14 -- How to
    deal with embedded time stamps -- open</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; <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'>&lt;<cite>trackbot</cite>&gt; ISSUE-14 How to
    deal with embedded time stamps closed</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; ISSUE-16?</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; 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'>&lt;<cite>trackbot</cite>&gt; <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'>&lt;<cite>Yves</cite>&gt; issue-13?</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; ISSUE-13 -- Write
    a IETF draft for proposing how to register the fragment scheme
    for all media types -- open</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; <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'>&lt;<cite>trackbot</cite>&gt; 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'>&lt;<cite>scribe</cite>&gt; ... 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'>&lt;<cite>hackerjack</cite>&gt; +1</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; +1</p>

    <p class='phone'><cite>PROPOSED:</cite> the document is good
    enough to be a Last Call</p>

    <p class='irc'>&lt;<cite>davy</cite>&gt; +1</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; +1</p>

    <p class='irc'>&lt;<cite>Wim</cite>&gt; +1</p>

    <p class='phone'>+1</p>

    <p class='irc'>&lt;<cite>hackerjack</cite>&gt; +1</p>

    <p class='irc'>&lt;<cite>erik</cite>&gt; +1</p>

    <p class='phone'>Silvia has agreed also</p>

    <p class='phone'>no objections</p>

    <p class='irc'>&lt;<cite>erik</cite>&gt; s/agrees/agreed</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; see <a href=
    "http://www.w3.org/2005/08/online_xslt/xslt?xmlfile=http://www.w3.org/2005/08/01-transitions.html&amp;xslfile=http://www.w3.org/2005/08/transitions.xsl&amp;docstatus=lc-wd-tr">
    http://www.w3.org/2005/08/online_xslt/xslt?xmlfile=http://www.w3.org/2005/08/01-transitions.html&amp;xslfile=http://www.w3.org/2005/08/transitions.xsl&amp;docstatus=lc-wd-tr</a></p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; 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'>&lt;<cite>scribe</cite>&gt;
    <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'>&lt;<cite>trackbot</cite>&gt; 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'>&lt;<cite>erik</cite>&gt; 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'>&lt;<cite>erik</cite>&gt; Thx Davy!</p>

    <p class='phone'>close ACTION-176</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; 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'>&lt;<cite>davy</cite>&gt; 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 />

  &nbsp;<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: &lt;jack&gt; ...
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>