09-mediafrag-minutes.html 90.7 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 -- 09 Mar
  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>Media Fragments Working Group Teleconference</h1>

  <h2>09 Mar 2010</h2>

  <p><a href=
  'http://www.w3.org/2008/WebVideo/Fragments/wiki/FifthF2FAgenda'>Agenda</a></p>

  <p>See also: <a href=
  "http://www.w3.org/2010/03/09-mediafrag-irc">IRC log</a></p>

  <h2><a name="attendees" id="attendees">Attendees</a></h2>

  <div class="intro">
    <dl>
      <dt>Present</dt>

      <dd>Davy, Erik, Jack, Yves, Franck_(observer), Raphael,
      Silvia_(remote), Conrad_(remote), Philip_(remote),
      Michael_(remote)</dd>

      <dt>Regrets</dt>

      <dt>Chair</dt>

      <dd>Erik, Raphael</dd>

      <dt>Scribe</dt>

      <dd>Raphael</dd>
    </dl>
  </div>

  <h2>Contents</h2>

  <ul>
    <li>
      <a href="#agenda">Topics</a>

      <ol>
        <li><a href="#item01">1. First day summary</a></li>

        <li><a href="#item02">2. HTTP headers discussion</a></li>

        <li><a href="#item03">3. Implementation Report</a></li>

        <li><a href="#item04">4. Test Cases review</a></li>

        <li><a href="#item05">5. Wrap Up</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: 09 March
    2010</p>

    <p class='irc'>&lt;<cite>scribe</cite>&gt; scribenick:
    raphael</p>

    <p class='irc'>&lt;<cite>scribe</cite>&gt; Scribe: Raphael</p>

    <h3 id="item01">1. First day summary</h3>

    <p class='phone'><cite>Raphael:</cite> I would suggest to start
    today's agenda with 2 short discussion:<br />
    ... a) What should be the delimiter in the URI for specifying
    multiple tracks: comma or semi-colon</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; was it understood
    and found acceptable that whatever separator we use can then
    not be part of the track name, even if it's
    percent-encoded?</p>

    <p class='phone'><cite>Raphael:</cite> b) Whether we should
    revisit the delimiter in the URI for specifying the time
    dimension and use the dash instead of the comma</p>

    <p class='phone'>Philip, no, the separator could be used in a
    track (or id) name if it is percent-encoded</p>

    <p class='phone'>Why would you you prevent to use it?</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; Because
    percent-decoding happens before matching against each
    syntax</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; I sent a rather long
    mail about layering just now, somewhat related.</p>

    <p class='phone'>Philip, the room agrees with what you just
    said ... there are 2 solutions</p>

    <p class='phone'>a) We quote :-)</p>

    <p class='phone'>b) We forbid multiple tracks selection for the
    1.0 version, so there is no delim and no problem</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; basically, the only
    bulletproof solution is: don't use names :)</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; trackbot,
    minutes?</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; Sorry, jackjansen,
    I don't understand 'trackbot, minutes?'. Please refer to
    <a href=
    "http://www.w3.org/2005/06/tracker/irc">http://www.w3.org/2005/06/tracker/irc</a>
    for help</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; why was
    track=a&amp;track=b not ok?</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; pointer</p>

    <p class='phone'>Philip, we will discuss this on the phone in 5
    minutes, could you join?</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; wait a sec</p>

    <p class='phone'>Philip, track=a&amp;track=b is not valid since
    any fragment with multiple occurrence of 't' or 'xywh' or
    'track' or 'id' will be invalid</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; phone number?</p>

    <p class='phone'>Philip, hold on, phone in 5 minutes</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; ok</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; raphael: we can just
    make multiple occurences of track valid, can't we?</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; Philip, that
    would break for libraries that decode only the first of each
    name=value pairs</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; jackjansen: yes, but
    so would t=1&amp;t=2, which processing needs to handle (but it
    shouldn't be valid)</p>

    <p class='phone'>Philip, t=1&amp;t=2 is indeed invalid per our
    syntax</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; raphael: invalid,
    but the result of processing it the same as if t=2 was used</p>

    <p class='phone'>the problem is that if you have multiple
    occurences of key=value with the same key, is that some
    libraries just take the last one</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; yes, which is why
    there is a note in the spec warning about the issue</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; should I call in
    now?</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; what if somebody else
    decide that t=1&amp;t=2 means something else? Like generate two
    streams, starting at different times?</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; somebody else, meaning
    out of our spec</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; we shouldn't define an
    uber-error-recovery mechanism that forbid all reuse and
    enhancements</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; Yves: they would
    simply be violating our spec</p>

    <p class='phone'>so this is not the same: in case of
    #t=10&amp;t=20 ... invalid fragment, the complete resource is
    sent back</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; foolip, yes, so if you
    implement only mediafrag, you'll get all the data, if you
    implement their spec, you'll do the "right thing"</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; having country code
    troubles</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; I thought we had
    already discussed this enough times</p>

    <p class='phone'>Philip, what did we already discuss
    enough?</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; nope, dialing in
    gets me a busy tone or nothing at all</p>

    <p class='phone'>Philip, on the phone Silvia argues, based on
    section 2.2 of the URI draft, that all reserved characters are
    treated equally</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; what jack just
    explained was how I understood it</p>

    <p class='phone'><cite>scribe:</cite> so #track=audio,video
    will work</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; we have the reserved
    characters exactly for the purpose of making sub-delimiters</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; raphael: tried +1
    and +44</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; the percent-encoding
    should not happen on the complete content value, but only on
    the segmented values (after separating on sub-delimiters)</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; raphael: just tried
    it, no luck</p>

    <p class='phone'>Philip, Silvia just contradicts your previous
    statement, re: we will not be able to have a comma in a track
    name</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; we just need to make
    the parsing &amp; %encoding different</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; we can make it work,
    but then we will also have to change how name-value processing
    works and make percent decoding happen later</p>

    <p class='phone'>Yes Philip</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; another
    incompatability with existing languages, just to be clear</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; if the argument
    against track=a&amp;track=b is that it breaks existing tools,
    using a new separator does the same</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; are there other
    problems with track=a&amp;track=b?</p>

    <p class='phone'>Philip, the WG_Room + Silvia thinks that using
    one of the subdelim as defined in URI spec is the right thing
    to do ... subdelim are made for that</p>

    <p class='phone'><cite>scribe:</cite> so not breaking existing
    tools</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; raphael: sure, but
    is it worth introducing more incompatibilities?</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; name-value lists
    already provides a way to repeat the same name</p>

    <p class='phone'><cite>Jack:</cite> as soon as there is a UTF-8
    character, you will need to decode the string and re-encode the
    string according to RFC2047<br />
    ... so we don't need to have a correlation between what is in
    the URI and what ends-up in the HTPP headers</p>

    <p class='phone'><cite>Silvia:</cite> yes, but in most of the
    case, there will be ASCII characters so we could ease
    implementers work</p>

    <p class='phone'><cite>Jack:</cite> this is an invit for lazing
    coding<br />
    ... I agree with you with the practical case, but we are
    editing a spec<br />
    ... we should try to follow patterns set by other RFC spec</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; hu?</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; I dropped
    ...</p>

    <p class='phone'><cite>Silvia:</cite> i would not object on
    that ... you have a point</p>

    <p class='phone'><cite>Raphael:</cite> should we stand with
    yesterday's resolution, i.e. keep the semi-colon as
    separator?</p>

    <p class='phone'><cite>Jack:</cite> I have checked 2 cgi
    libraries and indeed, Philip is right, that makes in practice
    the use of ';' forbidden in track names</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; I disagree with
    using a separator</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; Yves is ok with
    multiple &amp;track=</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; let's continue,
    enough time wasted on phones today :)</p>

    <p class='phone'><cite>Proposal:</cite> a new resolution that
    contradicts yesterday's resolution. Multiple tracks selection
    will be possible using multiple occurrence of the keyword
    'track' (e.g.: #track=audio&amp;track=video)</p>

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

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

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

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

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

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

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; :-)</p>

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

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

    <p class='phone'><strong class='resolution'>RESOLUTION: a new
    resolution that contradicts yesterday's resolution. Multiple
    tracks selection will be possible using multiple occurrence of
    the keyword 'track' (e.g.:
    #track=audio&amp;track=video)</strong></p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; perl.....
    brrr......</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; is the delimiter
    controversial?</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; hihi</p>

    <p class='phone'><cite>Raphael:</cite> we need to apply many
    changes in the whole document</p>

    <p class='phone'><cite>Philip:</cite> I have also edited the
    spec</p>

    <p class='phone'><cite>Raphael:</cite> please check in</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; breaking up too much
    right now</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; silvia: which bridge
    did you use?</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; no, there's no CVS
    web interface that I know of</p><a name="action01" id=
    "action01"></a>

    <p class='irc'>&lt;<cite>scribe</cite>&gt;
    <strong>ACTION:</strong> Yves to change the formal syntax to
    reflect that we don't need a subdelim for selecting multiple
    tracks but we allow multiple track= in the URI [recorded in
    <a href=
    "http://www.w3.org/2010/03/09-mediafrag-minutes.html#action01">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action01</a>]</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; Created ACTION-152
    - Change the formal syntax to reflect that we don't need a
    subdelim for selecting multiple tracks but we allow multiple
    track= in the URI [on Yves Lafon - due 2010-03-16].</p><a name=
    "action02" id="action02"></a>

    <p class='irc'>&lt;<cite>scribe</cite>&gt;
    <strong>ACTION:</strong> Raphael to review the complete
    document and check whether there are mroe references to
    uniqueness [recorded in <a href=
    "http://www.w3.org/2010/03/09-mediafrag-minutes.html#action02">http://www.w3.org/2010/03/09-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 review the complete document
    and check whether there are mroe references to uniqueness
    [recorded in <a href=
    "http://www.w3.org/2010/03/09-mediafrag-minutes.html#action03">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action03</a>]</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; Created ACTION-153
    - Review the complete document and check whether there are more
    references to uniqueness [on Raphaël Troncy - due
    2010-03-16].</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; Yves: I will commit
    now, as it conflicts with the action you just got</p>

    <p class='phone'>Short dicussion: re-visiting the use of comma
    in definition of temporal definition in URI</p>

    <p class='phone'><cite>scribe:</cite> Conrad proposed to use a
    dash<br />
    ... Rejected by all the group<br />
    ... it just introduces more problem, uri syntax is not
    correlated to header syntax anyway</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; why is the delimiter
    important?</p>

    <p class='phone'>Conrad, object formally if you're not
    satisfied with this answer</p>

    <h3 id="item02">2. HTTP headers discussion</h3>

    <p class='phone'>Back to the other objection from Conrad, sent
    yesterday</p>

    <p class='phone'><cite>scribe:</cite> the use of the Range
    headers when there is another unit than bytes<br />
    ... we miss so far in our discussion the fact that there is
    synthetic headers<br />
    ... see also: <a href=
    "http://lists.w3.org/Archives/Public/public-media-fragment/2010Mar/0084.html">
    http://lists.w3.org/Archives/Public/public-media-fragment/2010Mar/0084.html</a></p>

    <p class='phone'>Silvia, Philip: look at <a href=
    "http://www.w3.org/2008/WebVideo/Fragments/wiki/MediaFragmentHeaders">
    http://www.w3.org/2008/WebVideo/Fragments/wiki/MediaFragmentHeaders</a></p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; raphael, I'm ok with
    not using a dash for start-end specification</p>

    <p class='phone'>Conrad, in the URL?</p>

    <p class='phone'>Conrad, are you ok with using a comma in the
    URL?, i.e. #t=10,20</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; committed some
    stuff, should make some of you cringe in pain ;)</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; raphael: except CVS
    is so terrible, when will we switch to git?</p>

    <p class='phone'><cite>Silvia:</cite> is the Content-Range in
    other units purely descriptive? ... I would think so</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; <a href=
    "http://lists.w3.org/Archives/Public/public-media-fragment/2010Mar/0084.html">
    http://lists.w3.org/Archives/Public/public-media-fragment/2010Mar/0084.html</a></p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; HTTP/1.1 206
    blah</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; Content-Range:
    t:npt=10-20/60</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt;
    Content-Range-Equivalent: bytes=16384-32768/65536</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; instead return:</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; HTTP/1.1 206
    blah</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt;
    Content-Range-Equivalent: t:npt=10-20/60</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; Content-Range:
    bytes=16384-32768/65536</p>

    <p class='phone'><cite>Silvia:</cite> we are not sending 16 kB
    but 20 kB since they are also the synthetic headers<br />
    ... so your change is just wrong</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; raphael, yes i am ok
    with using a comma in the url</p>

    <p class='phone'><cite>Jack:</cite> we want to stop
    old-fashioned try to cache fragments</p>

    <p class='phone'><cite>Silvia:</cite> NO NO NO, we don't send
    synthetic headers<br />
    ... this is what we have discussed the last 1/2 year<br />
    ... we return in the fragment only the bytes of the original
    resources</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; i don't recall that
    we agreed not to send synthetic headers, obviously we need to
    supply both the headers required for decode ("synthetic") and
    the media data</p>

    <p class='phone'><cite>Jack:</cite> for queries, we must have
    synthetic headers, it is OK, this is a new resource</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; if we use some form
    of referral to byte ranges for the media data, fine, but that
    is optional</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; that is a different
    issue to the overloading of Range though</p>

    <p class='phone'><cite>Silvia:</cite> indeed, we haven't taken
    yet a formal resolution</p>

    <p class='phone'><cite>Raphael:</cite> perhaps it is now time
    for :-)<br />
    ... so let's discuss whether there will be synthetic headers
    exchange in the case of fragments</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; i suggest that the
    response to a fragment url is a valid media stream</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; whether that does or
    doesn't require generating new headers, tailer data,
    intermediate data, referral files (.m3u, adaptive streaming
    etc.) or whatever is media-dependent</p>

    <p class='phone'>Conrad, does it mean to send synthetic
    headers?</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; raphael, for some
    media types like a raw ogg stream, sure; but that is not
    something to be specified by mfwg</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; here we can propose
    a mechanism for optimising that transfer, like an optional way
    of saying that some part of the representation can equivalently
    be gotten by a byte range retrieval</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; silvia, you
    become unintelligeble</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; breaking up...</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; jack was talking about
    phone quality ;)</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; in short, Silvia is
    100% right</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; conrad: no, the
    response to a fragment is a byte range - no media file
    headers</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; Michael: I
    can't hear you guys anymore</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; only the response to
    a query needs to headers</p>

    <p class='phone'><cite>Raphael:</cite> indeed, there is a
    contradiction between Silvia and Conrad's view</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; so where do you get
    the headers (required for decode) from?</p>

    <p class='phone'>Conrad, with another request</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; e.g. a Web browser
    has already set itself up for decoding a media file when it is
    asking for a later byte range</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; hm ... I can't
    get in. damn ... trying other line</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; in that case there
    is no new http header transaction to be specified anyway</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; it is just a
    client-side seek</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; oh - just got a
    mail from admins. seems like they have to reboot out
    (VoIP-based) phone system ... will try again as soon as the
    system is up again</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; will try calling
    into another bridge when summoned the next time</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; thanks raphael
    but I really really want to dail back in ASAP</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; conrad: no, the idea
    of 5.2.2 is to make an improvement over 5.2.1: e.g. instead of
    having to do bisection search with Ogg over network, you get to
    simply ask the server for the right byte ranges by asking for
    the time range or track ..</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; all URI fragment
    requests have to be handled the same way - none will require
    re-retrieving artificial file headers</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; I agree with Silvia
    that it's unlikely any browser will implement these headers</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; if you have an
    index, there's just no need.</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; for old Ogg files
    without an index, it still makes sense</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; we will not ever
    have all Ogg files with index and thus this is a way to improve
    on the bisection search problem</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; yes, but that's
    probably not reason enough to spend resources on it, we'd just
    tell people to use footool to add an index</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; I of course only
    make guesses on behalf of Opera</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; silvia, sure, in the
    case of no server interaction that makes perfect sense</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; well, it was the
    original motiviation for section 5.2.2 - but it may not be
    relevant much longer (unless the video element starts
    supporting other such file formats)</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; bah! but there *is*
    server interaction!</p>

    <p class='phone'><cite>Raphael:</cite> Silvia, Conrad and
    Philip, we are discussing in the room whether a fragment
    request should retrieve a playable resource (with synthetic
    headers) or just bytes from the original resource, or a
    multi-part reply</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; anyway - the
    situation for query is a different one and we can still use all
    of the above arguments to sort out the query case, which will
    indeed need to return a full media resource</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; raphael: the
    original resource, without a shadow of a doubt.</p>

    <p class='phone'>Yes, Silvia, we don't talk about query, since
    it is easy and we don't need to specify headers anyway ... it
    already works</p>

    <p class='phone'><cite>Jack:</cite> synthetic headers gives us
    problem</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; if we introduce
    header retrieval into media fragments now, we have to also
    change the way in which 5.2.1 works - and that doesn't make
    sense, because that's how browser vendors right now work</p>

    <p class='phone'><cite>Jack:</cite> I'm also more and more
    convinced that we should not sent them on the wire in the
    fragment case</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; not dealing with
    synthetic headers solves sooo many problems</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; if we introduce
    synthetic headers, we get a new media resource with a different
    start and end time - which will result in a different
    presentation</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; that should really
    be reserved for query only</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; indeed</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; it's the fundamental
    difference between fragments and queries: fragments === byte
    range requests, query === new resource</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; in that case we
    _never_ need anything else than byte ranges</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; silvia, the
    5.2.1 case is different, it uses byte-ranges</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; and we always need 2
    requests at minimum</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; other than in the
    case where the UA cannot resolve a time range to a byte
    range</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; but that doesn't
    invalidate the other points</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; no, Yves, the UA can
    send a request to the server for a time range and the server
    can reply with the appropriate byte range</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; that is what 5.2.2
    expresses</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; no because it's not
    playable, so you need extra information beforehand</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; (or after)</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 5.2.2 and 5.2.3 also
    use byte ranges</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; silvia, so you
    expect 2 exchanges (for 522): one in bytes to get the header,
    then one in npt to get the video data. Correct?</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; but if you got the
    data before, you might be able to do the mapping yourself and
    ask for bytes directly</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; Yves, yes, it is
    playable: it assumes the UA already has all the information to
    do something useful with the byte range</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; just as is the case
    with any other retrieval action that uses byte ranges</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; jack: I am assuming
    the headers have already been received earlier</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; it's playable if you
    have a-priori information about the data.</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; it not, then yes,
    you need to get the headers first</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; either you are
    mandating a specific container that have this characteristic,
    or you don't need this</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; only for OGG,
    actually - MPEG doesn't need that</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; Yves, with Ogg as it
    currently is, you cannot do the mapping yourself</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; sure it does, MPEG
    doesn't repeat the headers over and over does it?</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; at least not all
    versions</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; fix the container!</p>

    <p class='phone'>:-)</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; in any event: before
    spending lots of time trying to optimize away one network
    roundtrip, perhaps we should see if any implementor actually
    wants to solve this problem.</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; foolip: MPEG
    actually does repeat the headers over and over :)</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; Silvia, all
    newer formats have a header. So question is, do we do this work
    only for legacy formats?</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; (header: I mean
    one that includes enough info to seek)</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; Yves: we have fixed
    it and there is now a possibilty to put an Index into Ogg,
    which is why foolip said above that 5.2.2 will not be used very
    often</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; silvia: even MPEG-4?
    always?</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 5.2.2 is only a
    minimal improvement over 5.2.1</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; well, we've already
    done the work and it is a solution for any media format that
    has that problem, so I'd say we can safely leave it in the
    spec</p>

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

    <p class='irc'>&lt;<cite>silvia</cite>&gt; foolip: IIUC yes,
    MPEG-4 has a way to do that, but you'd better ask Eric</p>

    <p class='phone'>I'm trying to summarize where do we stand</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; I don't have a
    strong opinion, but would avoid spending time on it.</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 1. we need a
    decision that URI fragments always just retrieve a byte range
    and assume that the UA already knows how to decode that byte
    range</p>

    <p class='phone'>5.2.1: The UA is very clever, can do the
    mapping between seconds and bytes, send a Range request in
    bytes, almost no implementation is needed!</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 2. we need a
    decision if we want to remove 5.2.2 and 5.2.3 from the spec or
    leave it there for legacy formats</p>

    <p class='phone'>5.2.2: tiny optimiziation, the UA connot do
    the mapping, but there are still 2 requests, the first one, the
    UA got all the headers, the second one, the bytes of the data,
    the UA can play the file because of the first request with the
    headers, the Range request is expressed in seconds for
    example</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; except that getting
    the headers will only happen once and for all subsequence
    fragment requests it will only be one request</p>

    <p class='phone'>5.2.3: has actuallly 3 exchanges, the first is
    the same than for 5.2.2 where the UA has requested the headers
    to be able to play the resource later on</p>

    <p class='phone'>OK, so go back to 2 points from Silvia</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 5.2.3 does what
    5.2.2 does, but in a proxy-cachable manner</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; my interpretation is
    that byte ranges should be good enough for anyone provided the
    container is ok, for clients that will do 2 or more requests to
    get the data</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; i.e. the UA asks the
    server to send it the byte-range mapping and then does
    5.2.1</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; but it has latency
    issues</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; the goal of having
    time ranges is to do everything in one exchange, to reduce
    latency</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; 5.2.3 Proxy cacheable
    Server mapped byte ranges</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; is actually doing 3
    exchanges</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; (but it's fine!)</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; indeed, and this is
    why 5.2.1 will realistically be all that UAs do</p>

    <p class='phone'><cite>Jack:</cite> Silvia is right, 5.2.2 is
    just for legacy formats, it has no value overall</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; but there is
    optimisation along a different line for those that do 5.2.2:
    get proxy cachable requsts</p>

    <p class='phone'><cite>Jack:</cite> we can keep it just
    mentionning that this is for legacy formats</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; it already says so
    IIRC</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; note that even when
    asked for bytes only, we can send a header to indicate the
    mapping to time ranges</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; jut not in these
    words</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; Yves, we could, but
    the UA already knows that, so why would be bother destroying
    cachability in this way?</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; silvia, your solution
    for 5.2.2 is just helping bad container formats</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; indeed :)</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; for files that have
    been recorded live, getting an index is an extra effort</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; and thus, some files
    will never have that header</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; and I think that
    applies to both Ogg and MPEG</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; so it's not actually
    as unrealistic as one might think</p>

    <p class='phone'><cite>Raphael:</cite> Silvia, perhaps we
    should document the VERY first request for 5.2.2 and 5.2.3, the
    one where the UA got the headers of the media</p>

    <p class='phone'>Silvia, I agree, an action for you ?</p>

    <p class='phone'>I don't give it to you if do it now :-)</p>

    <p class='phone'>can you do a live edits to add this note?</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; agree on both</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; happy to make the
    change</p>

    <p class='phone'>ok, for the note, it is 2 min work</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; will do both now</p>

    <p class='phone'>for the other, it will require more work ...
    including changing the figures, you want a formal action?</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I don't think we
    need to add a figure</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; those two retrieval
    actions are independent of each other</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; they may need to
    occur together, but if the UA already has the header, it will
    not need to do that first retrieval action</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; so, I can just add a
    description of it and refer to 5.2.1 with some byte range from
    0</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; foolip: what byte
    range do you typically load for Ogg files?</p>

    <p class='phone'>Silvia, Yves objects on one thing (please
    listen)</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; silvia: start from
    the beginning and load until we need to seek to the end, where
    we get 8500 bytes, then back to wherever data is needed
    next</p>

    <p class='phone'>Yves considers that 5.2.2 is useless and
    should be removed ... for legacy formats, 5.2.3 should be
    used</p>

    <p class='phone'><cite>scribe:</cite> BUT, he sketchs another
    5.2.2</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; silvia: yes</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; I know, we have an
    open bug for it :)</p>

    <p class='phone'><cite>scribe:</cite> which is the original
    intention of the 2-ways handshake, where all data is sent</p>

    <p class='phone'>Jack is drawing on the board, pictures will
    come soon</p>

    <p class='phone'>Silvia, in 5.2.1, there is also this VERY
    first request to do, where the UA got the headers, so more
    things to add in the spec</p>

    <p class='phone'><cite>scribe:</cite> do you think you can do
    that in the next hour? or would you need more time?</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I wonder about the
    result on 5.2.2</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I didn't make
    changes because I was waiting for Yves' proposal</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; but maybe it's
    another proposal altogether and needs a 5.2.4 ?</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I will start working
    on 5.2.1 now</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; 5.2.2 as it is is
    useless, for legacy container 5.2.3 should be used</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; does the spec need
    to go into detail about what byte ranges may or may not be
    needed? it can't be normative anyway</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; (server side
    mapping)</p>

    <p class='phone'>Sylvia, indeed, don't change 5.2.2 since Yves
    and Jack come with a new nice proposal</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I've adapted
    5.2.1</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; and committed :)</p>

    <p class='phone'>Silvia, the note for legacy format should go
    in the section 5.2.3, phrased slightly differently, where we
    said, legacy formats that cannot do the mappping (give
    examples, such as the old ogg file) need to use 5.2.3
    description</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; it's actually
    irrelevant to the spec where the UA gets the information from
    how to map the fragment to byte ranges - it could come from
    previously stored information or a previous retrieval action or
    from guessing - it doesn't matter</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; so I just made that
    first paragraph more concrete</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; raphael: I disagree
    that 5.2.3 is a requirement for legacy formats</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; it is a possibility
    to use this, but not a necessity</p>

    <p class='phone'>ok silvia</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; and also, you need a
    collaborating server, which will be hard to get</p>

    <p class='phone'>did you change the figures in 5.2.1 ? we are
    mainly looking at that :-)</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; no, as I said: they
    don't need changing</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; it doesn't matter
    where the information for the mapping comes from</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; it's up to the UA to
    sort this out</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; it could come from a
    index file that it was given by a third party server or
    anything else</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; it could even just
    be guessing</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; so, there is not
    necessarily an additional retrieval action</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; also, 3.2 already
    describes different means of how the UA could get to that
    information</p>

    <p class='phone'>Silvia, the WG room thinks that it will be
    much clearer to add this information, and perhaps mark it
    specifically as header retrieval</p>

    <p class='phone'><cite>scribe:</cite> the proof being the
    misunderstanding of some members beforehand</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; there is no header
    retrieval for MPEG</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; some formats just
    have an index somewhere</p>

    <p class='phone'><cite>Philip:</cite> why did you remove the
    production of Segment? this is the hat on top of query and
    fragment!</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; we have to describe
    the most general case, not just Ogg</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; silvia,
    technically correct., but you will do an initial exchange</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; not necessarily</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; well you need to know
    the compression level</p>

    <p class='phone'>Exatly Silvia, that's why we think we should
    document how the information to be able to play the file has
    been obtained</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; Silvai, and more
    generally I would like to concentrate on modern formats.</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I, the UA, may have
    received the information from a third party of how to map time
    to byte ranges</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; it doesn't need to
    come through an extra interaction with this particular media
    resource</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; so technically you
    request some bytes at the beginning, not file headers, just do
    have infrmation for doing the mapping</p>

    <p class='phone'>yes, but for clarity, we should write that
    down somewhere in the spec</p>

    <p class='phone'>and you could write that this info has been
    obtained from a third-party</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; Yves: I do that for
    Ogg, yes</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; but not for MPEG</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I wrote that the UA
    has somehow obtained this information and I wrote an
    example</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I don't think we
    need to add a graphic for it since, there are so many cases</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; Silvia, how do
    you guess where to do your first seek, for (say) t=10,20?</p>

    <p class='phone'>Silvia, you agree that even in the case of
    MPEG, you need to know the compressiojn rate</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; yep, could have been
    given to me in the HTML markup</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; hmm, don't see
    that as a common use (but correct me if I'm wrong)</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; jackjansen:
    bisection search, first guess is based on something like total
    size (bytes) amd total duration (seconds)</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; there are proposals
    to put such information into the HTML spec</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; if we write into the
    spec that a first retrieval action has to retrieve the resource
    headers, interpret them, and thus extract the mapping of
    fragment addressing to byte range, then we are severely
    restricting how this spec can be used</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; we are prescribing
    something that people will need to ignore to actually make it
    work</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; hehe, I would simply
    ignore the spec if it said something like that</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; see :)</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; in fact I will
    ignore *anything* the spec says with regards to what requests
    to make, when to look in the cache, etc</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; there is an impact on
    latency</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; Yves, nothing that
    HTML5 doesn't already have</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; "I know just because
    it's a youtube URI that we have this format with this
    compression level" is a client-level hack that shouldn't be
    part of the discussion :)</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; there is no extra
    latency for a media fragment URI</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; yes, there is a
    latency problem, but I'd rather solve it with an index than by
    introducing special headers (which most headers won't
    understand)</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; Silvia, we are
    not saying it *has to* do this. We're saying it is probably
    going to be the common case.</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; which is what I
    described in words</p>

    <p class='phone'>WHich paragraph exactly Silvia?</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; no need for a
    graphic that would imply it always has to be done</p>

    <p class='phone'>First one in <a href=
    "http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-protocol-frag">
    http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-protocol-frag</a>
    ?</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 5.2.1</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; As described in
    section <a href=
    "http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#URIfragment-user-agent">
    http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#URIfragment-user-agent</a>,
    the most optimal case is a user agent that knows how to map
    media fragments to byte ranges. This is the case typically
    where a user agent has already downloaded those parts of a
    media resource that allow it to do or guess the mapping, e.g.
    headers or a resource, or an index of a resource.</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; Yves, if the UA
    already has a copy of the media resource in its local cache
    from a previous retrieval action days ago, it won't do another
    request either</p>

    <p class='phone'>OK, we seem to agree Silvia (you win a lot
    today)</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; it's hard work!</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 6 months!</p>

    <p class='phone'><cite>scribe:</cite> but in the existing
    figure, shows that the UA has already the headers<br />
    ... we have a nice drawing on board</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; Suggestion: we
    add a little blob to the client timeline saying "header already
    available or not needed"</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; it's not a
    information needed for playback of the fragment</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; it's a mapping that
    is available</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; fragment to byte
    range mapping already available</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; we agree that header
    is bad usage of "enough information to do the mapping" :)</p>

    <p class='phone'>Yes Silvia, this is also what Davy who reads
    in your mind say</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; excellent :)</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I trust Davy - he
    has implemented the bugger ;)</p>

    <p class='phone'>Jack, Yves: we change 5.2.2 to have just one
    round trip, similar to 5.2.1</p>

    <p class='phone'><cite>scribe:</cite> the request is epxressed
    in seconds for example<br />
    ... the server sends back a playable resource, the only
    question is whether the data parts contains the original
    headers of the media (that need to be changed by the UA) or new
    synthetic headers made by the serve<br />
    ... this is not cachable by legacy caches<br />
    ... it might be by future caches</p>

    <p class='phone'>Philip, you reply to me only?</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; actually, your
    description of 5.2.2 is exactly what 5.2.2 is</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; no headers
    included</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; only one roundtrip,
    just like 5.2.1</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; why should that
    fragment request contain a header when 5.2.1 doesn't ?</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; it needs enough
    information to play the file</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; just like 5.2.1, it
    already has set up the pipeline</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; so in some cases it
    can have headers, in some other cases, not</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; no, in 5.2.2 you MUST
    NOT need to have the information magically before doing the
    request</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; life is so much
    easier if all fragment requests just map to byte range
    requests</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; but it's not
    needed!</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; why would 5.2.2 be
    different to 5.2.1 ?</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; you have byte ranges
    for that :)</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; 5.2.2 as it stands has
    no value at all</p>

    <p class='irc'>&lt;<cite>davy</cite>&gt; I agree with Yves</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; handling legacy
    formats is 5.2.3</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; handling legacy
    formats using server-based mapping is 5.2.3</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; no, it's also
    5.2.2</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 5.2.3 is an
    improvement over 5.2.2</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; davy: why?</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; handling legacy
    content through byte ranges is 5.2.1</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; we haven't changed
    5.2.2 yet</p>

    <p class='phone'>we are discussing it</p>

    <p class='phone'>you want to join on the phone ?</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; ok ...</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; but I agree that my
    vision of 5.2.2 might not be implemented _now_ (or ever :) )
    but at least it has a value by reducing the latency and
    requiring only one exchange</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; <a href=
    "http://www.example.com/foo#t=10">http://www.example.com/foo#t=10</a>,20</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; what do you know
    beforehand about this thing?</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; =&gt; nothing apart
    that it may be a media fragment</p>

    <p class='phone'><cite>Raphael:</cite> *new* 5.2.2 is different
    than 5.2.1 since we do not need to have the prior information
    of mapping the seconds to bytes or the original information to
    play the media</p>

    <p class='phone'><cite>Silvia:</cite> it is another
    optimization</p>

    <p class='phone'><cite>Yves:</cite> no, 5.2.3 has also (like
    5.2.1) the same asumption than the UA has the information to
    play the media<br />
    ... so 5.2.3 is the optimization of 5.2.1<br />
    ... Range request always expressed in bytes</p>

    <p class='phone'><cite>Jack:</cite> again, I see now the value
    of 5.2.2<br />
    ... for example as follow on requests from the same media<br />
    ... someone click on the timeline to request another segment,
    but does not request once more the headers</p>

    <p class='phone'><cite>Raphael:</cite> I'm considerink asking
    Yves to write his new optimization in a section 5.2.4 and see
    later on if we can keep it or not</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I would be happy if
    we introduced a request type that just gets us the setup
    information</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; then that plus the
    existing 5.2.2 would be what Yves is proposing now</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; silvia, that
    will require two roundtrips again.</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; silvia, I would
    suggest as 5.2.4 a request that gets us setup information PLUS
    data</p>

    <p class='phone'>Silvia, what this mean &lt;silvia&gt; I would
    be happy if we introduced a request type that just gets us the
    setup information ?</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; jack is right: if we
    want to avoid a round trip, we need 5.2.4</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; incidentally, I am
    not sure how much browser vendors care about one additional
    round trip these days ;)</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; seeking on Ogg
    without an index typically requires several round trips (I've
    seen 7 and more) and that was bad, but once it was down to 3-4
    it was acceptable</p><a name="action04" id="action04"></a>

    <p class='irc'>&lt;<cite>scribe</cite>&gt;
    <strong>ACTION:</strong> Yves to add a section 5.2.4 describing
    his new optimization [recorded in <a href=
    "http://www.w3.org/2010/03/09-mediafrag-minutes.html#action04">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action04</a>]</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; Created ACTION-154
    - Add a section 5.2.4 describing his new optimization [on Yves
    Lafon - due 2010-03-16].</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; should I make some
    changes to 5.2.2 then?</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; as discussed
    before?</p>

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

    <p class='phone'><cite>Raphael:</cite> Attempt summary<br />
    ... 5.2.2 = request expressed in npt, anwers sent back in bytes
    + Content-Range equivalent<br />
    ... mandatory<br />
    ... or not :-)<br />
    ... 5.2.3 = server-based bytes mapping, redirect involve,
    cachable</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I think we can adapt
    the headers once Yves has done his 5.2.4 - we might want to
    harmonize</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; no need to adapt, we
    just reverse the use :)</p>

    <p class='phone'><cite>Raphael:</cite> 5.2.4 = unlike the 3
    other cases, we DON'T need to obtain first the mapping
    information (reduce latency), request expressed in npt,
    content-range expressed in the same unit, and content-range
    equivalent is in bytes</p>

    <p class='phone'>ok ?</p>

    <p class='phone'><cite>scribe:</cite> 5.2.4 is uncacheable for
    legacy caches, but might be cacheable with new ones</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; 5.2.2 doesn't have
    the mapping either</p>

    <p class='phone'>Silvia, 5.2.2 has the mapping, otherwise, how
    the file is played since this information is not sent</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; no, there is a
    difference between having the fragment to byte mapping and
    having the decoding pipeline set up</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; if 5.2.2 had the
    mapping , it would be 5.2.1</p>

    <p class='phone'>Silvia, ok, i'm talking only about decoding
    pipeline set up</p>

    <p class='phone'><cite>scribe:</cite> I'm not talking about the
    mapping, different terminology</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; so, 5.2.4: unlike
    the other cases, doesn't have the decoding pipeline set up for
    the file yet and obtains with the request also the necessary
    background information (headers etc)</p>

    <p class='phone'>Yes silvia</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; this reduced the
    retrieval action by one round trip</p>

    <p class='phone'>yes silvia</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; now, let me consider
    the headers...</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I think we need an
    extra header that says: send me the setup info, too</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; how else would the
    server know whether it has to just return the bytes or also the
    header bytes?</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; and … how does the
    UA know which bytes are header bytes and which are content
    bytes?</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; Feeling slightly
    confused for haviing to channel Silvia as well as myself:-)</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; like a 'transcode
    unit' flag</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; might be optional in
    range syntax</p>

    <p class='phone'><cite>Raphael:</cite> indeed, we need to
    differenciate at the protocol level that 5.2.2 and 5.2.4 are
    different, most likely new headers?<br />
    ... or different header syntax</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; Range: t:npt
    10-20;convert</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; even if we ignored
    5.2.2 and it use of HTTP header syntax: how would the server
    package the data in a way that the client knows it's just
    receiving the header info and some byte range later in the
    file?</p>

    <p class='phone'><cite>Raphael:</cite> perhaps it is part of
    Yves's action when describing the new 5.2.4 making sure it does
    not collide with 5.2.2</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; we also need to
    remember that we have defined that media fragments provide for
    a subpart of the main resource and that e.g. a player would
    display the full timeline</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; silvia, through the
    CRE, or a new "here is data" paramter or header or whatever</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; so, the reply needs
    to signal to the UA exactly what data belongs to what</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; ok, I'll wait till
    you've written it</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I just want to make
    sure we are on the same page in that this is NOT a new, shorter
    resource</p>

    <p class='phone'><cite>Raphael:</cite> the WG thinks we should
    have a new name that Content-Range-Equivalent</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; that's what the
    query is for</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; the goal is not to
    send synthetic headed (well, metainformation needed to DTRT),
    but the orignal one</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; no, query is
    identifying new resources</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; ok, cool</p>

    <p class='phone'>Silvia, in 5.2.4 you will still have the
    context, the full timeline of the original media</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; this is where we may
    still need to discuss with Conrad ;)</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I'm cool with it</p>

    <p class='phone'>OK, proposal for new header names?</p>

    <p class='phone'><cite>Proposal:</cite> Range-Mapping ?</p>

    <p class='phone'>This new header will be used in 5.2.2 and
    5.2.4</p>

    <p class='phone'><cite>scribe:</cite> in 5.2.2, Content-Ranges
    is expressed in bytes, and Range-Mapping in the unit of the
    original HTTP request<br />
    ... in 5.2.4, this is exactly the other way around</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; s/other way
    around/other way round/</p>

    <p class='phone'><cite>scribe:</cite> that conflicts with
    Conrad's opinion who thinks we should not have the Range header
    used with another unit than bytes</p>

    <p class='phone'>Silvia, are we done with that?</p>

    <p class='phone'><cite>scribe:</cite> we think we can have
    lunck break, demo time, tc reviews now</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; are we calling it
    Range-Mapping?</p>

    <p class='phone'>are you against?</p>

    <p class='phone'>silence = approval :-)</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I honestly don't
    care :)</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; but we didn't
    vote</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt;
    Content-Range-Equivalent was also just signifying the mapping
    :)</p>

    <p class='phone'><cite>Proposal:</cite> Call the only new
    introduced header 'Range-Mapping'</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; ok, I will make the
    change</p>

    <p class='phone'><cite>Proposal:</cite> call the only new
    introduced header: 'Content-Range-Mapping'</p>

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

    <p class='irc'>&lt;<cite>davy</cite>&gt; +1 for
    Content-Range-Mapping</p>

    <p class='phone'>+1 for Content-Range-Mapping</p>

    <p class='irc'>&lt;<cite>erik</cite>&gt; +1 for
    'Content-Range-mapping'</p>

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

    <p class='irc'>&lt;<cite>Yves</cite>&gt; +1 for
    "Content-Range-mapping"</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; +0</p>

    <p class='phone'><cite>Jack:</cite> I may have opinion on the
    syntax of this new header<br />
    ... I have no opinion on the name</p>

    <p class='phone'><strong class='resolution'>RESOLUTION:
    (pending no objection from Conrad+Philippe) A new header named
    'Content-Range-Mapping' will be introduced, used in sections
    5.2.2 and 5.2.4 at least, which purpose is to expressed a
    mapping of a Content Range between 2 units (e.g. bytes and
    seconds)</strong></p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; note that 5.2.3 also
    uses Content-Range-Mapping to signal back to the UA which range
    the provided byte range maps to</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; even 5.2.1 may use
    CRM</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; as metainformation</p>

    <p class='phone'><cite>Raphael:</cite> I agree with both
    remarks</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; but it reminds me that
    we should probably add a Cache-Control: no-store=" least, which
    purpose"</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; but it reminds me that
    we should probably add a Cache-Control:
    no-store="Content-Range-Mapping"</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; Yves: if we used CRM
    in 5.2.1, that would destroy cachability, right?</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; why?</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; it's meta-information,
    nothing more</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; because of the extra
    header</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; and old caches will
    ignore it</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; no, see the
    cache-control directive ;)</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; "don't store the
    header"</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; ok, so is 5.2.2
    cachable then?</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I guess because we
    use the new fragment dimensions on the Range header, they are
    not?</p>

    <p class='phone'><cite>Raphael:</cite> Conrad, I want to
    clarify one of your wrong asumption in one of your email for
    yesterday night<br />
    ... you wrote, don't use comma separated value for selecting
    multiple tracks in the Content-Range headers<br />
    ... but we can, since Content-Range header cannot be split</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; <a href=
    "http://www.ietf.org/rfc/rfc2617.txt">http://www.ietf.org/rfc/rfc2617.txt</a>
    (about the use of ',' in headers, and splitting)</p>

    <p class='phone'><cite>Raphael:</cite> similar to
    Authorization<br />
    ... so: "Content-Range: track audio1,audio2" will be
    valid<br />
    ... hope it clarifies this objection you have</p>

    <p class='phone'><cite>Yves:</cite> I will have some
    clarification about that from HTTPbis in our meeting in 2
    weeks<br />
    ... if this changes, I will warn you</p>

    <p class='phone'>Conrad, would you like an action to add your
    use case in the UC document?</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; raphael,
    yes</p><a name="action05" id="action05"></a>

    <p class='irc'>&lt;<cite>scribe</cite>&gt;
    <strong>ACTION:</strong> davy to draw diagrams to include in
    the spec, similar to Yves's email, that shows which bytes from
    the headers and body of the media file are sent [recorded in
    <a href=
    "http://www.w3.org/2010/03/09-mediafrag-minutes.html#action05">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action05</a>]</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; Created ACTION-155
    - Draw diagrams to include in the spec, similar to Yves's
    email, that shows which bytes from the headers and body of the
    media file are sent [on Davy Van Deursen - due
    2010-03-16].</p><a name="action06" id="action06"></a>

    <p class='irc'>&lt;<cite>scribe</cite>&gt;
    <strong>ACTION:</strong> Conrad to add a "bandwidth
    conservation use case" [recorded in <a href=
    "http://www.w3.org/2010/03/09-mediafrag-minutes.html#action06">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action06</a>]</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; Created ACTION-156
    - Add a "bandwidth conservation use case" [on Conrad Parker -
    due 2010-03-16].</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; raphael, concerning
    the comma, i object more strongly to using Content-Range for
    that anyway :-)</p>

    <p class='phone'>Conrad, to use Content-range for track?</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; ie. i prefer a new
    header for time ranges etc., for which comma and header
    combining is allowed</p>

    <p class='phone'>Conrad, you want Range and Content-Range only
    used with the bytes unit?</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; raphael, to use
    Content-Range for bytes (no change to existing implementations)
    and to use a new header to advertise the time range of the
    representation</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; raphael, yes</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; 206 requires a CR</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt;
    s/CR/Content-Range/</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; (or a multipart
    byterange, that contains Content-Range headers)</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; in fact it's not even
    sure that we can do the range mapping in another header</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; generally i would
    like us to specify things so that the responses are cacheable
    with existing proxies, and i think that is well possible</p>

    <p class='phone'>Conrad, see section 5.2.3</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; yes, use byte
    ranges</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; ok, will
    review</p><a name="action07" id="action07"></a>

    <p class='irc'>&lt;<cite>scribe</cite>&gt;
    <strong>ACTION:</strong> Silvia to propagate the changes in the
    spec document now we have the new header
    'Content-Range-Mapping' [recorded in <a href=
    "http://www.w3.org/2010/03/09-mediafrag-minutes.html#action07">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action07</a>]</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; Created ACTION-157
    - Propagate the changes in the spec document now we have the
    new header 'Content-Range-Mapping' [on Silvia Pfeiffer - due
    2010-03-16].</p>

    <p class='phone'><cite>Jack:</cite> I'm warning everybody that
    it is likely we go in LC with the non-possibility of combining
    dimensions in a fragment URI</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; my action has
    already been done and committed</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; s/in a fragement
    URI/in the HTTP protocol</p>

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

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; ACTION-157
    Propagate the changes in the spec document now we have the new
    header 'Content-Range-Mapping' closed</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; raphael: why add
    them back?</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; we cannot define the
    syntax in one single layer unless we can come up with the
    syntax for expressing "any string that after percent-decoding
    and decoding UTF-8 is equal to the unicode string x"</p>

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

    <p class='irc'>&lt;<cite>silvia</cite>&gt; Jack confused me
    :)</p>

    <p class='phone'>and then LC in June as expected</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; Yves: can you
    explain what changes you want to revert and why?</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; It is obvious that
    there is no common understanding of how things ought to
    work</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; maybe he has a
    syntax</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; that would be great,
    but I'd like to know or we'll just do this all over again
    later.</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; I want to have generic
    syntax + serialization ones</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; so for the URI
    serialization, it shouldn't contradict your algorithm</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; ok, what is the
    generic syntax?</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; basically, unencoded
    name=value</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; unencoded?</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; well, raw strings in
    utf-8</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; I'll do that
    tonight</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; probably by email
    first</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; on the URI
    fragment/query component level the data is percent-encoded
    bytes, how can a generic syntax be in terms of something
    unencoded?</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; is the mediafragment
    production I added not the generic syntax? even though we
    should perhaps rename it to something like namevalues to avoid
    confusion</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; URI fragment/query is
    part of the URI serialization</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; so it will be
    encoded</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; Yes, sure</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; but can that be
    expressed in declarative syntax?</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; I just want to know
    that there is actually some change and not just putting back
    the old syntax which doesn't match what we want implementations
    to match against.</p>

    <p class='phone'><cite>Raphael:</cite> I suggest Yves send by
    email tonight what he intends to change to finalize the
    discussion</p>

    <h3 id="item03">3. Implementation Report</h3>

    <p class='phone'><cite>Raphael:</cite> we will first start with
    a demo from Davy</p>

    <p class='phone'><cite>Davy:</cite> I will first show
    slides<br />
    ... URL to be provided soon<br />
    ... room laughing at the title<br />
    ... " Development of a flash player supporting media fragments:
    frustrations and results"<br />
    ... requirements: flash media frgaments player, could be used
    in any browser supporting Flash, communication with Ninsuna or
    any Media Fragments compliant server<br />
    ... we want to finally play the media fragments in the UA<br />
    ... how to integrate Flash video player with Media Fragments
    servers, 3 possible solutions</p>

    <p class='phone'>s/frgaments/fragments</p>

    <p class='phone'><cite>scribe:</cite> 1st approach: trivial use
    of the Flash video component<br />
    ... takes an input a URI pointing to a MP4 file<br />
    ... problem: no possibility to change the HTTP headers, so does
    not work<br />
    ... 2nd approach: use the HTTP communication component<br />
    ... make use of URLLoader component, possibility to add/set
    HTTP headers<br />
    ... problem: browsers only allow modifications of non-standard
    HTTP headers<br />
    ... it might be different with JavaScript (Philip, HELP
    !!!)<br />
    ... URLLoader and video component are not integrated<br />
    ... workaround: save received byte stram in a file ... not
    possible in an AIR application, no progressive play
    possible<br />
    ... IE, Firefox and Safari all show the same behavior,
    communication between the flash api and the browser, my
    parameters are blocked and the browser prohibit to change the
    standard HTTP header<br />
    ... 3rd approach: write an own flash video component, take as
    input the URLLoader component, requires a huge effort<br />
    ... or modify existing flash video component<br />
    ... only possible with help from Adobe</p>

    <p class='phone'><cite>Raphael:</cite> Philip, it would be very
    great if you could react on that, based on your experience with
    Opera, is this possible at all for a browser plugin to interact
    with the browser and change the HTTP headers<br />
    ... e.g. a plugin that catchs up the media fragment URI syntax,
    and just send a bytes range request<br />
    ... that is NOT possible for sure with a Flash component
    interacting with a browser according to Davy experiment</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; No, it's not
    possible to add arbitrary HTTP headers, and as far as I know
    not any headers at all, not via the netscape plugin API at
    least.</p>

    <p class='phone'><cite>Raphael:</cite> Davy said you can add
    non standard headers, you cannot modify the default ones!</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; Perhaps flash has
    its own HTTP stack that completely bypasses the browser, or
    there is more to the netscape API than I have seen.</p>

    <p class='phone'><cite>Davy:</cite> conclusion is in order to
    support Media Fragments, players MUST be modified</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; foolip:
    XMLHttpRequest allows setting HTTP headers</p>

    <p class='phone'><cite>Raphael:</cite> Silvia, can you override
    the ones from browser?</p>

    <p class='phone'><cite>Davy:</cite> Media Fragments flash
    player</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; raphael: yes</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; silvia: Is that
    actually implemented by most browsers? In either case, this
    shouldn't be available to plugins.</p>

    <p class='phone'><cite>Davy:</cite> able to play any mp4
    file</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; foolip: I don't know
    if plugins can use it, but you can write it in a Web page</p>

    <p class='phone'><cite>Raphael:</cite> Philip, are you
    suggesting then that the code of the browsers will need to be
    modified?</p>

    <p class='phone'><cite>Davy:</cite> demo = <a href=
    "http://ninsuna.elis.ugent.be/MediaFragmentsPlayer">http://ninsuna.elis.ugent.be/MediaFragmentsPlayer</a></p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; I doubt it will ever
    be possible from plugins if it doesn't already work. I'm sure
    it doesn't work in Opera via plugins because byte ranges
    weren't very well supported before &lt;video&gt;</p>

    <p class='phone'><cite>Raphael:</cite> Philip, then how do you
    think UA should become media fragment aware? Does Opera plan to
    change the browser code in order to generate Range request?</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; We have already done
    it for &lt;video&gt;, supporting media fragments is just a
    matter of parsing a string and seeking to an offset (more or
    less)</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; foolip: I think
    setRequestHeader is implemented by all browsers, even as early
    as this <a href=
    "http://www.jibbering.com/2002/4/httprequest.html">http://www.jibbering.com/2002/4/httprequest.html</a>
    &lt;- it is available</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; silvia: XHR?</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; yes, part of
    that</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; then it isn't
    available to plugins (Flash), if that's the problem Davy
    had</p>

    <p class='phone'><cite>Raphael:</cite> Philip, the whole point
    of Media Fragment URI is not to seek to an offset, but generate
    a Range Request to get portions of video clips</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; <a href=
    "http://en.wikipedia.org/wiki/XMLHttpRequest">http://en.wikipedia.org/wiki/XMLHttpRequest</a>
    &lt;- see setRequestHeader</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; raphael: seeking is
    implemented with range requests, that's what I mean.</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; internally it will
    be the same thing, with some fluff for the UI presentation
    perhaps and special behavior when looping</p>

    <p class='phone'><cite>Raphael:</cite> philip, ok, thanks for
    the clarification, so I understand that we can use Javascript
    to simulate now new headers generation based on a parsing of
    the Media Fragment URI</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; yes, that's possible
    today, but you'll get to see the first frame of the video for a
    while until the seek is finished.</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; which the browser
    would hide in a native implementation</p>

    <p class='phone'><cite>Raphael:</cite> and that browsers, such
    as Opera, will change their code to support media
    fragment?<br />
    ... or am I hoping too much?</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; I can't promise
    anything, it depends on our priorities and how sane we can get
    the processing of media fragments to be</p>

    <p class='phone'><cite>Raphael:</cite> amazing demo from
    Davy</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; (which is the reason
    I joined the group)</p>

    <p class='phone'><cite>Raphael:</cite> supports already t,
    track and xywh dimensions !!!</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; nice job, Davy!</p>

    <p class='phone'><cite>Raphael:</cite> even the space dimension
    nicely rendered in the UA</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; Yves: not really,
    I'd like the spec to be good as a whole too :)</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; foolip :)</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; to repeat, I don't
    care how things are defined as they allow sane implementation
    that allows future spec changes and progressive
    implementation.</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; ... as long as
    ...</p>

    <p class='phone'><cite>Raphael:</cite> I agree with this goal
    too :-)</p>

    <p class='phone'>Give it a try with <a href=
    "http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4">http://www.w3.org/2008/WebVideo/Fragments/media/fragf2f.mp4</a></p>

    <p class='phone'><cite>scribe:</cite> we not have a cropping on
    only Silvia on the screen, all the rest is black<br />
    ... spatial selection + temporal selection done</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; take a photo!</p>

    <p class='phone'><cite>Raphael:</cite> Philip, could you
    explain us WHY flash cannot set headers and Javascript can
    using the XMLHttpRequest</p>

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

    <p class='phone'><cite>scribe:</cite> why browsers block one
    way and not the other way?</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; I think there's just
    no API for it, but it's been a while since I looked at the
    netscape plugin API.</p>

    <p class='phone'><cite>Raphael:</cite> pointing to <a href=
    "http://www.jibbering.com/2002/4/httprequest.html">http://www.jibbering.com/2002/4/httprequest.html</a></p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; I really don't know
    what Flash does, if it has a separate cache, if it bypasses the
    browsers HTTP stack, etc etc.</p>

    <p class='phone'><cite>Jack:</cite> it is from 2002 !!!</p>

    <p class='phone'><cite>Davy:</cite> yes, my code would also
    have worked few years ago<br />
    ... the blocking is recent</p>

    <p class='phone'><cite>Raphael:</cite> we are not sure we will
    not get blocked with Javascript either!<br />
    ... we need to test</p>

    <p class='phone'>Silvia, do you follow tis?</p>

    <p class='phone'>s/tis/this</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; Davy: did you try
    FlashXMLHttpRequest?</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; <a href=
    "http://blog.monstuff.com/archives/000294.html">http://blog.monstuff.com/archives/000294.html</a></p>

    <p class='irc'>&lt;<cite>davy</cite>&gt; no, that is another
    possibility to sort out</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; In any case using
    XMLHttpRequest to get the video data sounds a bit...
    creative.</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; it is - and only
    useful when you're trying to demonstrate the use without
    touching player code</p>

    <p class='phone'><cite>Raphael:</cite> exactly :-)</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; foolip: I'd much
    prefer you put native support into Opera!</p>

    <p class='phone'><cite>Raphael:</cite> indeed Silvia, Philip
    the goal is to convince browsers vendors to change their code
    showing them prototypes, but we ALL prefer native support</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; silvia: I'd like
    that too :) Still, I don't set the priorities so I can't make
    promises.</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; The only reason I'm
    here is of course because I think doing MF is worthwhile.</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; Davy: also make sure
    to take care of the crossdomain stuff, e.g. <a href=
    "http://ejohn.org/blog/cross-site-xmlhttprequest/">http://ejohn.org/blog/cross-site-xmlhttprequest/</a></p>

    <p class='phone'><cite>Jack:</cite> I will have a look at
    having a pythong+Gstreamer implementation</p>

    <p class='phone'>s/pythong/python</p>

    <p class='phone'><cite>scribe:</cite> similar to what Davy did
    client side but in python</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; GStreamer :)</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; Michael: many
    excuses - system still seems not to work, can't dial in (but
    doesn't matter now as I have to drop in 15 min, anyway)</p>

    <p class='irc'>&lt;<cite>guillaume</cite>&gt; ref: <a href=
    "http://lists.w3.org/Archives/Public/public-media-fragment/2009Aug/0004.html">
    http://lists.w3.org/Archives/Public/public-media-fragment/2009Aug/0004.html</a></p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; Is the room actually
    doing "Review all actions and issues and discuss / close as
    appropriate"?</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; Michael: My
    take on the TC would be - review them and I'll update then in
    the Wiki (see also <a href=
    "http://lists.w3.org/Archives/Public/public-media-fragment/2010Mar/0086.html)">
    http://lists.w3.org/Archives/Public/public-media-fragment/2010Mar/0086.html)</a></p>

    <p class='phone'>ACTION-147?</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; ACTION-147 --
    Michael Hausenblas to add all MF WG members to corrib -- due
    2010-03-05 -- OPEN</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; <a href=
    "http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/147">
    http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/147</a></p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; yes, as I wrote
    - having issues with corrib; unsure if it is wise to continue
    with it</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; michael, for the
    time being or forever?</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; well, depends
    on when I have some spare time to fix it, jackjansen ;)</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; I'd recommend
    to keep it in the Wiki for the time being</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; I can still add
    it to corrib later on</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; important
    action is to review them, now</p>

    <p class='phone'><cite>Davy:</cite> I think corrib is a very
    useful tool for us, shame we cannot use it</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; Michael: agree
    with Davy</p>

    <p class='phone'>Michael, are you suggesting we just review all
    test cases, and the you take the burden to: 1/ update wiki
    pages, 2/ update corrib if this is necessary one day, etc.
    ?</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; yes,
    raphael</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; please just
    make sure that you do RESOLUTION: for each TC</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; so that I can
    point to it</p>

    <p class='phone'>Michael, can you show us the RDF generated by
    corrib ?</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; yes</p>

    <p class='phone'>is it somewhere in the group directory in
    cvs?</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; no</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; go to <a href=
    "http://ld2sd.deri.org/corrib/">http://ld2sd.deri.org/corrib/</a></p>

    <p class='phone'>a url pointer?</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; click Dashboard
    ...</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; under export
    ...</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; <a href=
    "http://ld2sd.deri.org/corrib/corrib.php?export=v1-mediafrag&amp;format=rdf-xml">
    http://ld2sd.deri.org/corrib/corrib.php?export=v1-mediafrag&amp;format=rdf-xml</a></p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; RDF/XML for
    example</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; but also in
    RDFa or via SPARQL endpoint</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; Michael, is
    there an import as well?</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; not at the
    moment, jackjansen</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; but I planed to
    do it</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; worth an
    issue/feature request</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; <a href=
    "http://bitbucket.org/mhausenblas/corrib/issues/">http://bitbucket.org/mhausenblas/corrib/issues/</a></p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; ok, chaps,
    sorry - gotta run now. will catch up later, reading minutes and
    anticipating some actions for /me</p>

    <h3 id="item04">4. Test Cases review</h3>

    <p class='phone'><cite>Raphael:</cite> WG room made great
    progress in listing all test cases we want for the temporal
    dimension<br />
    ... that makes 32 test cases<br />
    ... 2 full boards, pictures taken, need to be filled within a
    table</p><a name="action08" id="action08"></a>

    <p class='irc'>&lt;<cite>scribe</cite>&gt;
    <strong>ACTION:</strong> Raphael to enter this big table in the
    wiki [recorded in <a href=
    "http://www.w3.org/2010/03/09-mediafrag-minutes.html#action08">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action08</a>]</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; Sorry, couldn't
    find user - Raphael</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; are there test cases
    for e.g. #t=1&amp;t=2, or #%74=%6ept%3A%310 ?</p><a name=
    "action09" id="action09"></a>

    <p class='irc'>&lt;<cite>scribe</cite>&gt;
    <strong>ACTION:</strong> Troncy to enter the big table of all
    test cases for the temporal dimension in the wiki [recorded in
    <a href=
    "http://www.w3.org/2010/03/09-mediafrag-minutes.html#action09">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action09</a>]</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; Created ACTION-158
    - Enter the big table of all test cases for the temporal
    dimension in the wiki [on Raphaël Troncy - due 2010-03-16].</p>

    <p class='phone'>#t=1&amp;t=2 ... not yet, since we just did
    temporal dimension, syntax and semantic test, and not yet
    combination</p>

    <p class='phone'>#%74=10 is included</p>

    <p class='phone'>so #t=%31%30 is also</p>

    <p class='phone'><cite>scribe:</cite> wait for the table to see
    that fully :-)</p>

    <p class='phone'>Oh, if the unit is %-encoded ... need to add
    these ones too</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; ok, sounds good, we
    should be testing all kinds of weird input</p>

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

    <h3 id="item05">5. Wrap Up</h3>

    <p class='phone'><cite>Raphael:</cite> we need one more F2F
    meeting<br />
    ... possibility in Raleigh with WWW, who can be there?<br />
    ... Raphael, Davy, (Yves = no), (Jack = no?)</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; Raleigh, North
    Carolina?</p>

    <p class='phone'><cite>Raphael:</cite> Michael (likely)</p>

    <p class='phone'>Yes Philip, at WWW 2010, in April</p>

    <p class='phone'><cite>scribe:</cite> Conrad and Silvia: not
    impossible</p>

    <p class='irc'>&lt;<cite>foolip</cite>&gt; oh, can't make it,
    I'm (very willingly) stuck in Beijing until June</p>

    <p class='phone'><cite>Raphael:</cite> what are the other
    possibilities?<br />
    ... Sophia Antipolis, host by Yves<br />
    ... Hot topic net telecon</p>

    <p class='phone'>s/net/next</p>

    <p class='phone'><cite>Erik:</cite> beginning of June may be
    the best time<br />
    ... around June 10 ?</p>

    <p class='phone'><cite>Raphael:</cite> I will send summary of
    today's meeting in few hours</p>

    <p class='phone'>[meeting adjourned]</p>
  </div>

  <h2><a name="ActionSummary" id="ActionSummary">Summary of Action
  Items</a></h2><!-- Action Items -->
  <strong>[NEW]</strong> <strong>ACTION:</strong> Conrad to add a
  "bandwidth conservation use case" [recorded in <a href=
  "http://www.w3.org/2010/03/09-mediafrag-minutes.html#action06">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action06</a>]<br />

  <strong>[NEW]</strong> <strong>ACTION:</strong> davy to draw
  diagrams to include in the spec, similar to Yves's email, that
  shows which bytes from the headers and body of the media file are
  sent [recorded in <a href=
  "http://www.w3.org/2010/03/09-mediafrag-minutes.html#action05">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action05</a>]<br />

  <strong>[NEW]</strong> <strong>ACTION:</strong> Raphael to enter
  this big table in the wiki [recorded in <a href=
  "http://www.w3.org/2010/03/09-mediafrag-minutes.html#action08">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action08</a>]<br />

  <strong>[NEW]</strong> <strong>ACTION:</strong> Raphael to review
  the complete document and check whether there are mroe references
  to uniqueness [recorded in <a href=
  "http://www.w3.org/2010/03/09-mediafrag-minutes.html#action02">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action02</a>]<br />

  <strong>[NEW]</strong> <strong>ACTION:</strong> Silvia to
  propagate the changes in the spec document now we have the new
  header 'Content-Range-Mapping' [recorded in <a href=
  "http://www.w3.org/2010/03/09-mediafrag-minutes.html#action07">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action07</a>]<br />

  <strong>[NEW]</strong> <strong>ACTION:</strong> Troncy to enter
  the big table of all test cases for the temporal dimension in the
  wiki [recorded in <a href=
  "http://www.w3.org/2010/03/09-mediafrag-minutes.html#action09">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action09</a>]<br />

  <strong>[NEW]</strong> <strong>ACTION:</strong> troncy to review
  the complete document and check whether there are mroe references
  to uniqueness [recorded in <a href=
  "http://www.w3.org/2010/03/09-mediafrag-minutes.html#action03">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action03</a>]<br />

  <strong>[NEW]</strong> <strong>ACTION:</strong> Yves to add a
  section 5.2.4 describing his new optimization [recorded in
  <a href=
  "http://www.w3.org/2010/03/09-mediafrag-minutes.html#action04">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action04</a>]<br />

  <strong>[NEW]</strong> <strong>ACTION:</strong> Yves to change
  the formal syntax to reflect that we don't need a subdelim for
  selecting multiple tracks but we allow multiple track= in the URI
  [recorded in <a href=
  "http://www.w3.org/2010/03/09-mediafrag-minutes.html#action01">http://www.w3.org/2010/03/09-mediafrag-minutes.html#action01</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/03/09 14:30:11 $
  </address>

  <div class="diagnostics"></div>
</body>
</html>