16-mediafrag-minutes.html 50.5 KB

Raw Blame History Permalink

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html lang='en' xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
  <meta name="generator" content=
  "HTML Tidy for Linux/x86 (vers 12 April 2005), see www.w3.org" />

  <title>Media Fragments Working Group Teleconference -- 16 Apr
  2009</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>16 Apr 2009</h2>

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

  <p>See also: <a href=
  "http://www.w3.org/2009/04/16-mediafrag-irc">IRC log</a></p>

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

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

      <dd>conrad, michael, jack, erik, davy,
      frank_(canon_observer), raphael, dave_singer, silvia_(phone),
      yves_(phone)</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. Administrative</a></li>

        <li><a href="#item02">2. Yves/Silvia/Conrad: Specification
        discussion</a></li>

        <li><a href="#item03">discoverability</a></li>

        <li><a href="#item04">Numbers of documents</a></li>
      </ol>
    </li>

    <li><a href="#ActionSummary">Summary of Action Items</a></li>
  </ul>
  <hr />

  <div class="meeting">
    <p class='phone'>&nbsp;</p>

    <p class='phone'>&nbsp;</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; Date: 16 April
    2009</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; to fill you in:
    we can physically call, but we may run into trouble with uni
    burocracy here.</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; Will try
    something else.</p>

    <p class='phone'>Silvia, you can use the phone number and code
    above</p>

    <p class='phone'><cite>scribe:</cite> but you will be alone on
    the phone</p>

    <p class='phone'>we will phone through skype</p>

    <p class='phone'>but get the mic and speaker from a laptop</p>

    <p class='phone'>interim solution till lunch, when we hope to
    talk to MIT guys that can call us</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; yves: is the
    thing that needs to be done at MIT a one-time action? i.e. if
    they do the magic later today, will we be able</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; ... to use the
    speakerphone tomorrow morning?</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; jack; I will ask what
    is possible</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; we R in!</p>

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

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

    <h3 id="item01">1. Administrative</h3>

    <p class='phone'>Agenda is at: <a href=
    "http://www.w3.org/2008/WebVideo/Fragments/wiki/ThirdF2FAgenda">
    http://www.w3.org/2008/WebVideo/Fragments/wiki/ThirdF2FAgenda</a></p>

    <p class='phone'>Chairs would like to ammend the agenda, and
    start with a proposal to publish our FPWD</p>

    <p class='phone'><cite>scribe:</cite> needs the group
    approval</p>

    <p class='phone'><cite>Silvia:</cite> I think I have corrected
    all the markup errors</p>

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

    <p class='phone'><cite>PROPOSAL:</cite> publish the document at
    <a href=
    "http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/">
    http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/</a>
    as a first public working draft</p>

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

    <p class='irc'>&lt;<cite>silvia</cite>&gt; no objections -
    publication approved</p>

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

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

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

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

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

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

    <p class='phone'>Please, dave, so you have any objections to
    publish <a href=
    "http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/">
    http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/</a>
    as a FPWD?</p>

    <p class='irc'>&lt;<cite>dsinger</cite>&gt; no, we can publish
    and continue to revise, that's fine</p>

    <p class='irc'>&lt;<cite>dsinger</cite>&gt; I mean, no
    objections</p>

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

    <p class='phone'><strong class='resolution'>RESOLUTION: The
    Media Fragments agree to publish its FPWD</strong></p>

    <h3 id="item02">2. Yves/Silvia/Conrad: Specification
    discussion</h3>

    <p class='phone'>* discuss the story of the single-step vs
    dual-step partial GET (aka 2-ways, 4-ways handshake);</p>

    <p class='phone'>o discuss the Silvia's proposal: new headers
    Accept-TimeURI, Accept-SpaceURI, Accept-TrackURI and
    Accept-NameURI;</p>

    <p class='phone'>o discuss Yves's proposal: a GET of the media
    header (so a few bytes, depending on how much is enough), and
    the server answers with that + one or more Link: headers
    linking to different mappings (time to bytes is an example) or
    at least a resolver URI, linking to the sub-resource, to parent
    etc...</p>

    <p class='phone'>o discuss the pro/cons of each solution</p>

    <p class='phone'>* check with the evolving link header
    draft;</p>

    <p class='phone'>* Yves: present the clarifications of
    HTTPBis.</p>

    <p class='irc'>&lt;<cite>dsinger</cite>&gt; I have detailed
    comments, I'll try to get them to the group over these two
    days</p>

    <p class='phone'>Yves, can you call to hear us ?</p>

    <p class='phone'>we are on the phone</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; blog: <a href=
    "http://blog.gingertech.net/2008/11/10/media-fragment-uri-addressing/">
    http://blog.gingertech.net/2008/11/10/media-fragment-uri-addressing/</a></p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; read the last
    comment - FYI</p>

    <p class='phone'><cite>Yves:</cite> we need to clarify, in the
    dual step partial GET, how the resolution between time ranges
    and bytes work</p>

    <p class='phone'><cite>Silvia:</cite> the WD now explains how
    it works</p>

    <p class='phone'>Yves is reading <a href=
    "http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/#dual-step">
    http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/#dual-step</a></p>

    <p class='phone'><cite>Yves:</cite> there is something wrong in
    the first reply, you have a Content-Range but a 200 OK
    response<br />
    ... if there is a Content-Range header, it should be a 206
    response</p>

    <p class='phone'>Michael, I think a 100 response means the
    server sends something, and then something else but no
    interaction from the UA in the middle</p>

    <p class='phone'><cite>scribe:</cite> while in our case the UA
    remakes its request</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; Michael: I
    agree with silvia re caching header but not caching the entire
    message for scalability reasons</p>

    <p class='phone'><cite>Yves:</cite> first concern should be on
    user experience rather than caches/proxies efficiency .... they
    would anyway tune the right way the softwares</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; not sure,
    raphael re 100 response is totally out of question</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; Yves? what's
    your opinion on this?</p>

    <p class='phone'><cite>Silvia:</cite> for spatial fragments,
    there is no way we can cache things anyway</p>

    <p class='phone'><cite>Yves:</cite> I'm not sure we should
    forbid transcoding<br />
    ... I would ask for more people</p>

    <p class='phone'><cite>Silvia:</cite> your problem seems to be
    that there is 2 requests<br />
    ... TBL had the same feeling in Cannes<br />
    ... but the first request has no real data, so no delay</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; correction: but the
    first request retreives real data, so it is not unnecessary</p>

    <p class='phone'><cite>Yves:</cite> I would approach some TAG
    members informally</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; so having two HTTP
    request/response cycles does not introduce noticeable overhead
    in retrieving large amounts of data</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; Yves:
    headers+keyframes are not fake data</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; they are, as they are
    not part of the resource representation</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; Yves, i respectfully
    disagree, they are a necessary part of the segment
    representation</p><a name="action01" id="action01"></a>

    <p class='irc'>&lt;<cite>scribe</cite>&gt;
    <strong>ACTION:</strong> Yves to ask the TAG whether
    transcoding should be forbidden or not when we send a fragment
    of a resource [recorded in <a href=
    "http://www.w3.org/2009/04/16-mediafrag-minutes.html#action01">http://www.w3.org/2009/04/16-mediafrag-minutes.html#action01</a>]</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; Created ACTION-62
    - Ask the TAG whether transcoding should be forbidden or not
    when we send a fragment of a resource [on Yves Lafon - due
    2009-04-23].</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; of the segment, yes,
    but not the whole resource, which is addressed by the first get
    :)</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; plus there may be a
    mismatch of content between the first and second request</p>

    <p class='phone'><cite>Jack:</cite> the current WD does not say
    which anwsers has headers data and which ones has just
    headers</p>

    <p class='phone'><cite>Conrad:</cite> let me explain how things
    will work<br />
    ... I tend to see that the dual step is just a fallback of the
    single step</p>

    <p class='phone'>Conrad's schema:</p>

    <p class='phone'><cite>Conrad:</cite> user request URL =
    <a href=
    "http://www.example.com/video.ogg?t=10">http://www.example.com/video.ogg?t=10</a>,20</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; We lost our
    network.</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; And our
    phone.</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; Time for
    coffee.</p>

    <p class='phone'><cite>Yves:</cite> in temporal URI for
    annodex, we only used ? for remote retrievals - # was done
    locally only in the client</p>

    <p class='phone'>trackbot, start teleco</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; Sorry, raphael, I
    don't understand 'trackbot, start teleco'. 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='phone'>trackbot, start telecon</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; Meeting: Media
    Fragments Working Group Teleconference</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; Date: 16 April
    2009</p>

    <p class='phone'>Yves with ? you have no problem, you just
    return the whole fragment with header as a response to the GET,
    no need to to anything extra</p>

    <p class='phone'><cite>Yves:</cite> as ...?t=1,2 is different
    form ?t=2,3 and won't be cached as the same resource by caches
    anyway</p>

    <p class='phone'><cite>Conrad:</cite> back to the explanation,
    I explain how temporalURI works</p>

    <p class='irc'>&lt;<cite>philipj</cite>&gt; hi all</p>

    <p class='irc'>&lt;<cite>philipj</cite>&gt; I browsed through
    <a href=
    "http://www.w3.org/2008/WebVideo/Fragments/wiki/ThirdF2FAgenda">
    http://www.w3.org/2008/WebVideo/Fragments/wiki/ThirdF2FAgenda</a>
    but couldn't figure out which parts were on teleconf</p>

    <p class='irc'>&lt;<cite>philipj</cite>&gt; would be nice if
    the next F2F were in Stockholm, since I live not too far from
    there :)</p>

    <p class='phone'>this is the agenda for the 2 days, we are now
    on the first topic: Specification discussion</p>

    <p class='phone'>Conrad agree with Yves's point</p>

    <p class='phone'>Re: ? vs #</p>

    <p class='phone'>Conrad will continue his explanation of
    TemporalURI</p>

    <p class='phone'><cite>Conrad:</cite> URL = <a href=
    "http://www.example.com/video.ogv?t=10">http://www.example.com/video.ogv?t=10</a>,20<br />

    ... Client do a GET URL<br />
    ... with a new header: Accept-Range-Refer: bytes<br />
    ... Server: it udnerstands the range referal<br />
    ... will answer a 200 OK<br />
    ... with new headers: Range-Refer: this, 0-1000</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; <a href=
    "http://www.example.com/video.ogv?t=10">http://www.example.com/video.ogv?t=10</a>,20
    is a plain URI, unrelated to <a href=
    "http://www.example.com/video.ogv.">http://www.example.com/video.ogv.</a>
    Why not serving the content directly?</p>

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

    <p class='phone'><cite>Conrad:</cite> ... Range-Refer: URL2,
    a-b<br />
    ... Vary: Range-Refer and the body</p>

    <p class='phone'><cite>Client:</cite> will make another GET
    URL-2 request with the range a-b</p>

    <p class='phone'><cite>Jack:</cite> in the case the server does
    not understand the ?t=10,20 ... it will answer a 404</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; will answer with a
    404... that depends on the server configuration</p>

    <p class='phone'><cite>Jack:</cite> while in the case the
    server does not understand the #t=10,20 the way we want, it
    will send the whole resource, better for the UA</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; in some cases the ?
    will be ignored and you will save in a cache 100+ times the
    full content (attached to different URIs)</p>

    <p class='phone'><cite>Yves:</cite> this is a URI the server
    does not know about ... how can it be different from a 404
    ?</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; raphael, try to access
    <a href="http://www.w3.org/">http://www.w3.org/</a> and
    <a href="http://www.w3.org/?foo=bar">http://www.w3.org/?foo=bar</a></p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; that example work with
    lots of other servers ;)</p>

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

    <p class='irc'>&lt;<cite>Yves</cite>&gt; so accessing <a href=
    "http://media.exampe.com/bigvideo.mp4">http://media.exampe.com/bigvideo.mp4</a>
    <a href=
    "http://media.exampe.com/bigvideo.mp4?t=1">http://media.exampe.com/bigvideo.mp4?t=1</a>,2</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; will cache twice the
    big content</p>

    <p class='irc'>&lt;<cite>philipj</cite>&gt; unrecognized query
    strings will almost certainly be ignored by most servers, not
    return 404</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; all because of a quite
    common server configuration issue</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; (as the right thing
    would be to return a 404)</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; ok. So people
    shouldn't issue ? temporal uris to non-capable servers.</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; jack, yes, basically
    you need to know in advance</p>

    <p class='irc'>&lt;<cite>philipj</cite>&gt; sounds rather
    unreliable</p>

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

    <p class='irc'>&lt;<cite>philipj</cite>&gt; btw, is it worth
    saying things on IRC or do I need to join by phone? I happen to
    not have a phone nearby.</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; I still think that if
    you have <a href=
    "http://media.example.com/media?t=1">http://media.example.com/media?t=1</a>,10
    should return the fragment with the header as a complete
    resource</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; might also want
    to take <a href=
    "http://www.w3.org/2001/tag/doc/whenToUseGet.html#safe">http://www.w3.org/2001/tag/doc/whenToUseGet.html#safe</a>
    into consideration ...</p>

    <p class='irc'>&lt;<cite>philipj</cite>&gt; Yves, haha, ok
    then</p>

    <p class='phone'>yep, this is what Conrad said too !</p>

    <p class='phone'><cite>Yves:</cite> fragment + header meaning a
    complete resource</p>

    <p class='phone'><cite>Conrad:</cite> we will just ONE round
    trip, and a 200 OK in the case of a capable server
    understanding temporalURI<br />
    ... what is the fallback plan?</p>

    <p class='irc'>&lt;<cite>philipj</cite>&gt; how can one detect
    if the server does not understand temporalURI?</p>

    <p class='irc'>&lt;<cite>philipj</cite>&gt; sorry, I will be
    afk for lunch</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; wondering why
    the server shouldn't just send a 501 <a href=
    "http://tools.ietf.org/html/rfc2616#section-10.5.2">http://tools.ietf.org/html/rfc2616#section-10.5.2</a></p>

    <p class='phone'>Conrad answer: in temporal URI, the client
    uses another header: Accept-TimeURI</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; mhausenblas, in which
    case?</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; what philipj
    was asking and we are discussing here, now (server does not
    understand temporalURI?)</p>

    <p class='phone'><cite>scribe:</cite> further: the header in
    the ogg file returned will contain a In-point=10, so the client
    knows he didn't get the full resource, but this is media format
    dependant<br />
    ... it will work for ogg, perhaps for mp4, but certainly not
    for avi for example</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; or, how are
    odds that HTTPbis will introduce a new code for that case
    ...</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; Yves, yes I
    guess you are right, so just for the record, 501 is NO option,
    right?</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; (I was wondering if
    you meant "if the server doesn't know how to handle it, it
    should reply with a 501', which is againt the 'ignore what you
    don't understand' paradigm)</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; so yes 501 is not an
    option</p>

    <p class='phone'><cite>Raphael:</cite> let's kick out the ? for
    now, and work on the #</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; s/which is
    against/which is against</p>

    <p class='phone'><cite>Jack:</cite> our premises are that the
    client are easy to modify, while your asumption is that you
    think we should adop servers</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; +1 to raphael's
    proposal to focus on the #</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; if the # implies
    client sending a range request, then the server would do the
    work</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; raphael: is
    drawing a table</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; and the client will do
    the work as a fallback</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; the intention
    is to capture/structure the current state</p>

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

    <p class='phone'><cite>raphael:</cite> two cases at the
    table<br />
    ... either the UA makes a request using a unit like sec which
    is transformed into range request<br />
    ... and the server knows how to handle the mapping</p>

    <p class='phone'>Conrad agrees so far</p>

    <p class='phone'><cite>raphael:</cite> the second case is where
    we need a resolver</p>

    <p class='phone'>Conrad again on the board</p>

    <p class='phone'><cite>Conrad:</cite> client - GET URL,
    Aceept-TimeURI, Media-Fragment: t=10,20<br />
    ... Server: 206 partial content (with body, H' + K + D2)</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; For the people
    not in the room: the original media is H + D1 + D2 + D3</p>

    <p class='phone'>and Server: Content-Range: in sec and bytes
    (?)</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; ... D1 is
    seconds 0-10, D2 10-20, D3 20-30.</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; ... H' is
    modified header, K is synthetic keyframes etc. to be able to
    interpret D2 correct.</p>

    <p class='phone'><cite>Conrad:</cite> let's assume the URI is
    .../video.ogg#t=smpte-25:00'10.23.25,<br />
    ... hence we need to specify the unit in the Range</p>

    <p class='phone'><cite>raphael:</cite> if we specify the unit
    in the Range, we can agree on that?</p>

    <p class='phone'><cite>jackjansen:</cite> I ran into the same
    issue when implementing it</p>

    <p class='phone'>Yves, we are back</p>

    <p class='phone'><cite>raphael:</cite> sums up last 5min</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; a new header won't
    trigger partial responses</p>

    <p class='phone'><cite>raphael:</cite> Conrad suggests to
    introduce a new header and let the server do the magic</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; the right way would be
    in this case to do conneg and point to a CL and a Vary, but in
    that case we mandate multiple URIs, and defeat caches again
    ;)</p>

    <p class='phone'><cite>Conrad:</cite> this was my first issue
    with Range:<br />
    ... now second</p>

    <p class='phone'>(scribe notes that we have not yet fully
    resolved this issue)</p>

    <p class='phone'>Yves, in *which* case - new header?</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; if a new
    Media-Fragment: header is introduced in place of Range</p>

    <p class='phone'>ok, thanks for the clarification</p>

    <p class='phone'>Conrad drawing UA - Proxy - Original
    Server</p>

    <p class='phone'><cite>Michael:</cite> note what 206 (<a href=
    "http://tools.ietf.org/html/rfc2616#section-10.2.7)">http://tools.ietf.org/html/rfc2616#section-10.2.7)</a>
    says about caching ...</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; michael, see also
    <a href=
    "http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-06">http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-06</a></p>

    <p class='phone'>ta, Yves, was hoping that you come up with a
    recent state ;)</p>

    <p class='phone'>is there a big difference?</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; no small
    clarifications only</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; in rfc2616, the text
    was open to new units, but without any way of doing it, in
    httpbis it has been clarified</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; Yves: summary, we
    understand the concern of Conrad: single step partial GET, with
    a 206 response works, but it is not cachable</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; ... which we know,
    written in 7.3 !</p>

    <p class='phone'><cite>Michael:</cite> are we seeking a
    trade-of between cachability and round-trip?</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; in current web
    proxies not cachable</p>

    <p class='phone'><cite>jackjansen:</cite> yes</p>

    <p class='phone'><cite>Conrad:</cite> no</p>

    <p class='phone'><cite>jackjansen:</cite> let' ignore the
    No-Cache for now, different issue</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; things we can add is a
    header in the reply indicating where D2 is and its relationship
    to bytes in the original file</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I agree with the
    addition of such a header</p>

    <p class='phone'><cite>jackjansen:</cite> we should optimise
    for the case where a URI is embedded in an Web page</p>

    <p class='phone'><cite>silvia:</cite> for example in youtube
    case, each time you click on a time-offset it's a different
    URI</p>

    <p class='phone'><cite>jackjansen:</cite> do I understand
    correctly: every time I click on it I get a new URI?</p>

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

    <p class='phone'><cite>raphael:</cite> let's move on<br />
    ... we seem to agree on the one-step process but the cachable
    part</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; in the YouTube case
    there is a special server and a proprietary client - we cannot
    really tell what is going on; but when you click on an offset,
    a new connection is opened and new buffering is started</p>

    <p class='phone'><cite>jackjansen:</cite> a super-clever proxy
    would cache the entire bits and handle the parts
    accordingly</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; and a not so clever
    proxy could return the same content when the same second range
    is requested</p>

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

    <p class='irc'>&lt;<cite>Yves</cite>&gt; 'second' or 'other
    unit then bytes'</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; Conrad would like
    to move on the 4-ways handshake</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; but adding a mapping
    header in the reply (if possible would be a good thing, and
    only 'informative', so nothing mandatory to implement on the
    receiving end</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; gui walks in</p>

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

    <p class='irc'>&lt;<cite>Yves</cite>&gt; and that would help a
    lot Silvia and Conrad's use case</p>

    <p class='phone'>Guilleaume has arrived</p>

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

    <p class='phone'>+1 as well from me</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; Conrad: I don't
    think doing 200 response or 206 response should be our goal</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; ... my solution
    will add new headers on the client side but would be pretty
    similar</p>

    <p class='phone'>Conrad now explains now his solution with #
    and no Range</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; I will take a
    picture of Conrad complet's proposal</p>

    <p class='phone'><cite>Conrad:</cite> GET URL,
    Accept-Range-Refer: bytes, Media-Fragment:t=10,20</p>

    <p class='phone'><cite>Server:</cite> 200 OK, body
    Hi+K+D2<br />
    ... and additionally a header in the response ...
    Content-Media-Fragment:t=10,20</p>

    <p class='phone'>(it's raining)</p>

    <p class='phone'><cite>Conrad:</cite> Range-Refer: this,
    0-1000</p>

    <p class='phone'>note that 'this' is meant verbatim</p>

    <p class='phone'><cite>Conrad:</cite> continuing Range-Refer:
    URL2, Varu: Range-Refer, body</p>

    <p class='phone'><cite>jackjansen:</cite> let's not use 'this'
    but just blank (?)</p>

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

    <p class='phone'>(we seem to agree to disagree)</p>

    <p class='phone'><cite>raphael:</cite> see no big difference
    between Conrad's proposal and what is in the current draft</p>

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

    <p class='phone'>Yves is leaving</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; PIctures are in
    <a href=
    "http://www.w3.org/2008/WebVideo/Fragments/meetings/2009-04-16-f2f_barcelona/">
    http://www.w3.org/2008/WebVideo/Fragments/meetings/2009-04-16-f2f_barcelona/</a></p>

    <p class='phone'><cite>jackjansen:</cite> we should structure
    the document in the fall-back flow<br />
    ... much easier to grock, then</p>

    <p class='phone'><cite>Michael:</cite> +1</p>

    <p class='phone'><cite>Silvia:</cite> can we modify the current
    draft and enhance it with Conrad's proposal?</p>

    <p class='phone'><cite>raphael:</cite> still need to understand
    better</p>

    <p class='irc'>&lt;<cite>philipj</cite>&gt; is the proposal to
    allow either or both of these methods?</p>

    <p class='irc'>&lt;<cite>philipj</cite>&gt; conrad's single and
    dual step GET</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; IIUC the one-step
    GET is preferrable, but it doesn't work with existing Web proxy
    caching infrastructure other than by keeping multiple copies;
    the two-step GET is for making media fragment URIs work with
    existing caching Web proxies</p>

    <p class='phone'><cite>raphael:</cite> re philipj's question,
    its a fallback-stack</p>

    <p class='irc'>&lt;<cite>philipj</cite>&gt; I see</p>

    <p class='phone'><cite>raphael:</cite> in most of the cases,
    URL and URL2 are identical</p>

    <p class='phone'>(scribe notes also that there are two or more
    servers involved)</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; where does a and b
    come from? are they 0 - 1000 ?</p>

    <p class='phone'><cite>raphael:</cite> before lunch two
    questions<br />
    ... (1) for me the UA does not know that it has to do another
    request</p>

    <p class='phone'>and these will be discussed/ansewered after
    lunch</p>

    <p class='phone'><cite>jackjansen:</cite> is the more general
    approach of Conrad worth it re the introduced complexity which
    is apparently much higher</p>

    <p class='phone'>+1</p><a name="action02" id="action02"></a>

    <p class='irc'>&lt;<cite>scribe</cite>&gt;
    <strong>ACTION:</strong> Conrad to update the Wiki with his
    more general approach with precisely the same exmples [recorded
    in <a href=
    "http://www.w3.org/2009/04/16-mediafrag-minutes.html#action02">http://www.w3.org/2009/04/16-mediafrag-minutes.html#action02</a>]</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; Created ACTION-63
    - Update the Wiki with his more general approach with precisely
    the same exmples [on Conrad Parker - due 2009-04-23].</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I still do not
    understand the different</p>

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

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; time for lunch.
    Silvia: will you still be here later?</p>

    <p class='phone'>sorry, silvia you will have to wait a bit -
    Conrad suggests to read his blog ;)</p>

    <p class='phone'>we will be back in roughly an hour</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; ok, I may not be
    back</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I'm rather tired
    tonight and the phone is really exhausting</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; but I will linger
    here</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I read the blog,
    which I found just as confusing :)</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; trackbot, start
    telcon</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; Meeting: Media
    Fragments Working Group Teleconference</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; Date: 16 April
    2009</p>

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

    <p class='phone'><cite>raphael:</cite> Yves please update us on
    HTTP Link: header</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; raphael, are you
    reffering to <a href=
    "http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-06">http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-06</a>
    ?</p>

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

    <p class='irc'>&lt;<cite>conrad</cite>&gt; "If a range unit is
    not understood in a request, a server MUST ignore</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; the whole Range
    header"</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; url for link header
    draft?</p>

    <p class='phone'><cite>Michael:</cite> see <a href=
    "http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0189.html">
    http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0189.html</a>
    for updates on HTTP Link:</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; <a href=
    "http://tools.ietf.org/html/draft-nottingham-http-link-header-04">
    http://tools.ietf.org/html/draft-nottingham-http-link-header-04</a></p>

    <p class='phone'><cite>jackjansen:</cite> if only partially
    available? say file is 100bytes, and I request 50 - 150, it
    will be cut of at 100?</p>

    <p class='phone'><cite>Yves:</cite> yes</p>

    <p class='phone'><cite>jackjansen:</cite> all our replies
    should hence also incl. the time range, not only the bytes</p>

    <p class='phone'><cite>raphael:</cite> we will also have to be
    more precisely in the edge cases handling and their
    explanation</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; if you always get 200
    you won't get fragments :)</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; <a href=
    "http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-06#section-3.2">
    http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-06#section-3.2</a></p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; is actually
    unit-agnostic</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; yep, I phrased that
    wrongly</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; "none of the</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; ranges-specifier
    values in this field overlap the current extent of</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; the selected
    resource"</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; In Conrad's
    proposal, in the case of the dual-step partial GET, the second
    request is still a normal Range request, so will get the normal
    206 (or 416) response code</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; ... only the first
    request will be answered by a 200 OK response, since it
    contains just the header + key frames data in the body</p>

    <p class='phone'><cite>jackjansen:</cite> so, if the query
    would be empty in any of the dimension, the result would be a
    416</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; <a href=
    "http://www.w3.org/2008/WebVideo/Fragments/meetings/2009-04-16-f2f_barcelona/">
    http://www.w3.org/2008/WebVideo/Fragments/meetings/2009-04-16-f2f_barcelona/</a></p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; <a href=
    "http://blog.kfish.org/2009/04/proposal-for-generalizing-byte-range.html">
    http://blog.kfish.org/2009/04/proposal-for-generalizing-byte-range.html</a></p>

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

    <p class='irc'>&lt;<cite>Yves</cite>&gt; that's bad</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; two axis to identify a
    resource :)</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; URI request +
    media-fragment header</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; why do you need to
    send H1+K in the first request as you do a request to URL2
    where you can send the whole thing?</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; because the answer
    of the second GET will be cached ?</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; what is the
    relationship between URL and URL2?</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; URL = URL 2</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; ... in most of the
    cases</p>

    <p class='phone'>90% yes ;)</p>

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

    <p class='irc'>&lt;<cite>raphael</cite>&gt; Jack: is your
    URL/URL2 re-inventing the http-redirect?</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; I don't get why we
    need this complexity. at worst we need to locate a resolver and
    get the API to call it</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; I *think* the main
    purpose is to have the cacheability feature on the code
    data</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; ... but I think we
    have it with the current dual-step partial GET</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; Conrad: we need to
    do a bytes redirection for the second request</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; Raphael: in the
    spec, we have currently: X-Range-Redirect (new header)</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; ... Yves, how will
    you tell the user agent needs to issue another request to get
    the core of the video data ? do we need this new header ?</p>

    <p class='phone'><cite>Michael:</cite> I would be very careful
    introducing complexity if the benefit is not totally clear and
    'fool-proof'; lowers implementation barriers if we keep it
    simple</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; Jack: well, it is
    good in theory to call for a resolver (do the mapping between
    bytes and seconds) ... but in practice, this resolver will need
    to construct K (the key frames)</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; ... thus access the
    media, thus be on the server</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; Raphael: Yves, what
    is not clear in the current draft (among others :-), is the
    content of the body response of the first request in the dual
    step GET</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; ... should we have
    just the video data header (H') constructed on the server ?</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; I think that the
    clarification using letters is quite good and shoul make it to
    the 2nd publication :)</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; ... should we add
    also K (the key frames)</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; do you have the
    picture with the H, K?</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; Yves, <a href=
    "http://www.w3.org/2008/WebVideo/Fragments/meetings/2009-04-16-f2f_barcelona/ogv_video_decomposition.jpg">
    http://www.w3.org/2008/WebVideo/Fragments/meetings/2009-04-16-f2f_barcelona/ogv_video_decomposition.jpg</a>
    for the H, H', K, etc.</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; Yves: in the
    current draft, we haven't specify what is in the BODY of each
    response, right ?</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; no, but we should</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; Conrad mentions
    that in his solution: 1st response body contains the H' and K
    (new information/bytes constructed on the server)</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; ... while the 2nd
    response body contains only bytes coming from the original
    file</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; in the single GET
    solution the returned content should be H' K D2</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; ... and UA does the
    concatenation to get a complete playable resource</p>

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

    <p class='irc'>&lt;<cite>raphael</cite>&gt; in the case of the
    dual-step ?</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; and we shold craft
    that header to define where D2 is and its relation to the whole
    resource, as bytes</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; how ?</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; like Range-Mapping:
    bytes 1234-2345/58588; original=11234-12345/39849384</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; (or annodex might have
    a better format for that already :) )</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; well, this is what
    Conrad proposes with its Range-Refer ... re his blog post
    :-)</p>

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

    <p class='irc'>&lt;<cite>Yves</cite>&gt; he proposes a way to
    redirect without redirecting</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; I propose a mapping
    header for caches</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; he proposes to send
    the headers in the body of the first request, and the real
    video data in the body of the second request</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; on different URIs</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; I will bring your
    position in the room</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; ... no no no,
    assume now that URI = URI2</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; then it will confuse
    caches :)</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; basically if URL=URL2
    the cache will flush what it cached at each request</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; well, the first
    response is not meant to be cached (just headers), the second
    one is a clear extract in terms of bytes of the resource and
    will be cached</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; the request is not
    the same</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; yeah, but a subsequent
    request on the same thing will invalidate what has just been
    cached</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; no, if this is not
    the same request ?</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; the second request
    is a normal Range request</p>

    <p class='phone'><cite>jackjansen:</cite> let's use an example
    video (from last F2F) and do practical experiments<br />
    ... and figure out how different formats (MPEG4, OGG) actually
    behave</p>

    <p class='phone'><cite>Michael:</cite> I second jackjansen
    proposal</p>

    <p class='phone'><cite>raphael:</cite> yes, let's do it and
    document in the Wiki</p>

    <p class='irc'>&lt;<cite>scribe</cite>&gt; Scribenick:
    guillaume</p>

    <h3 id="item03">discoverability</h3>

    <p class='phone'><cite>Previously:</cite> Describe Conrad
    solution using the example (http implementation wiki page) to
    be enhanced with Conrad proposal</p>

    <p class='phone'><cite>Conrad:</cite> what happen when we come
    across an URL&nbsp;like
    video.ogv#t=smpte-25=00'10.23.25,...</p>

    <p class='phone'>What would the code look like in the User
    Agent (the "smart" user agent)</p>

    <p class='phone'>It could be that the user agent split at the
    #, then after the request, start parsing what' s after the #
    (not good enough). It would have to check if it matches the
    syntax first. Reply comes back.</p>

    <p class='phone'>It' s the owner of the MIMIE type that
    understands what' s happening beyond the # (because so far, #
    "belongs / could be used" in any HTML document)</p>

    <p class='phone'>The server knows the MIME type, hence, the way
    to interpret the #etc...</p>

    <p class='phone'>ACTION mhausenblas Michael to write into the
    WD section 6.4, what the client should do with #everything
    after the hash : "Client Side Media Fragment Resolution"</p>

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

    <p class='irc'>&lt;<cite>dsinger</cite>&gt; servers don't get
    the # part, it's supposed to be stripped by the UA, isn't
    it?</p><a name="action03" id="action03"></a>

    <p class='irc'>&lt;<cite>raphael</cite>&gt;
    <strong>ACTION:</strong> Michael to write into the WD section
    6.4, what the client should do with #everything after the hash
    : "Client Side Media Fragment Resolution" [recorded in <a href=
    "http://www.w3.org/2009/04/16-mediafrag-minutes.html#action03">http://www.w3.org/2009/04/16-mediafrag-minutes.html#action03</a>]</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; Created ACTION-64
    - Write into the WD section 6.4, what the client should do with
    #everything after the hash : "Client Side Media Fragment
    Resolution" [on Michael Hausenblas - due 2009-04-23].</p>

    <p class='phone'>Coffee break time!</p>

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

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

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I will probably be
    asleep when you get back</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; looks like there is
    progress :)</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; raphael: we
    will do now the joint meeting with the Annotation WG</p>

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

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

    <p class='phone'>Use cases + requirements could make 1 separate
    document</p>

    <p class='phone'>the specification of the syntax would be the
    core document</p>

    <p class='phone'>Yeah, the teleconf is working</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; Michael: we
    should only go with the Syntax REC-Track</p>

    <p class='phone'>We are going to have the joint meeting with
    the Media Annotation WG</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; ... the Test
    Cases (TC) and the Implementation Report (IR) should be a Note
    only</p>

    <h3 id="item04">Numbers of documents</h3>

    <p class='phone'>1. Use cases &amp; Reqs</p>

    <p class='phone'>2. Synthax</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; raphael:
    current UC and Req will be split into UCR and Syntax doc</p>

    <p class='phone'>Action raphael Current UC and Req will be
    split into UCR and Syntax doc</p>

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

    <p class='irc'>&lt;<cite>raphael</cite>&gt; trackbot,
    status</p>

    <p class='phone'>Action Raphaël Current UC and Req will be
    split into UCR and Syntax doc</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; Created ACTION-65
    - Current UC and Req will be split into UCR and Syntax doc [on
    Raphaël Troncy - due 2009-04-23].</p>

    <p class='phone'>3. Potentialy a 3rd document with Test
    cases</p>

    <p class='phone'>University people would like to make
    publications out of the work we produce here at the MFWG.</p>

    <p class='phone'>We would then add all our names to the joint
    co-authored paper(s)</p>

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

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

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

    <p class='irc'>&lt;<cite>silvia</cite>&gt; +1 (papers are
    always good )</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; ;)</p><a name=
    "action04" id="action04"></a>

    <p class='irc'>&lt;<cite>raphael</cite>&gt;
    <strong>ACTION:</strong> Jack to look at the organisation of
    the 4th F2F meeting in Amsterdam on September 17-18 (just after
    IBC) [recorded in <a href=
    "http://www.w3.org/2009/04/16-mediafrag-minutes.html#action04">http://www.w3.org/2009/04/16-mediafrag-minutes.html#action04</a>]</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; Created ACTION-66
    - Look at the organisation of the 4th F2F meeting in Amsterdam
    on September 17-18 (just after IBC) [on Jack Jansen - due
    2009-04-23].</p><a name="action05" id="action05"></a>

    <p class='irc'>&lt;<cite>raphael</cite>&gt;
    <strong>ACTION:</strong> Erik to sync with Jean Pierre to get
    the edit units spec reference [recorded in <a href=
    "http://www.w3.org/2009/04/16-mediafrag-minutes.html#action05">http://www.w3.org/2009/04/16-mediafrag-minutes.html#action05</a>]</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; Created ACTION-67
    - Sync with Jean Pierre to get the edit units spec reference
    [on Erik Mannens - due 2009-04-23].</p><a name="action06" id=
    "action06"></a>

    <p class='irc'>&lt;<cite>raphael</cite>&gt;
    <strong>ACTION:</strong> Raphael to ask the Media Annotations
    WG to review our document [recorded in <a href=
    "http://www.w3.org/2009/04/16-mediafrag-minutes.html#action06">http://www.w3.org/2009/04/16-mediafrag-minutes.html#action06</a>]</p>

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

    <p class='irc'>&lt;<cite>raphael</cite>&gt; trackbot,
    status?</p><a name="action07" id="action07"></a>

    <p class='irc'>&lt;<cite>raphael</cite>&gt;
    <strong>ACTION:</strong> Raphaël to ask the Media Annotations
    WG to review our document [recorded in <a href=
    "http://www.w3.org/2009/04/16-mediafrag-minutes.html#action07">http://www.w3.org/2009/04/16-mediafrag-minutes.html#action07</a>]</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; Created ACTION-68
    - Ask the Media Annotations WG to review our document [on
    Raphaël Troncy - due 2009-04-23].</p>
  </div>

  <h2><a name="ActionSummary" id="ActionSummary">Summary of Action
  Items</a></h2><!-- Action Items -->
  <strong>[NEW]</strong> <strong>ACTION:</strong> Conrad to update
  the Wiki with his more general approach with precisely the same
  exmples [recorded in <a href=
  "http://www.w3.org/2009/04/16-mediafrag-minutes.html#action02">http://www.w3.org/2009/04/16-mediafrag-minutes.html#action02</a>]<br />

  <strong>[NEW]</strong> <strong>ACTION:</strong> Erik to sync with
  Jean Pierre to get the edit units spec reference [recorded in
  <a href=
  "http://www.w3.org/2009/04/16-mediafrag-minutes.html#action05">http://www.w3.org/2009/04/16-mediafrag-minutes.html#action05</a>]<br />

  <strong>[NEW]</strong> <strong>ACTION:</strong> Jack to look at
  the organisation of the 4th F2F meeting in Amsterdam on September
  17-18 (just after IBC) [recorded in <a href=
  "http://www.w3.org/2009/04/16-mediafrag-minutes.html#action04">http://www.w3.org/2009/04/16-mediafrag-minutes.html#action04</a>]<br />

  <strong>[NEW]</strong> <strong>ACTION:</strong> Michael to write
  into the WD section 6.4, what the client should do with
  #everything after the hash : "Client Side Media Fragment
  Resolution" [recorded in <a href=
  "http://www.w3.org/2009/04/16-mediafrag-minutes.html#action03">http://www.w3.org/2009/04/16-mediafrag-minutes.html#action03</a>]<br />

  <strong>[NEW]</strong> <strong>ACTION:</strong> Raphael to ask
  the Media Annotations WG to review our document [recorded in
  <a href=
  "http://www.w3.org/2009/04/16-mediafrag-minutes.html#action06">http://www.w3.org/2009/04/16-mediafrag-minutes.html#action06</a>]<br />

  <strong>[NEW]</strong> <strong>ACTION:</strong> Raphaël to ask
  the Media Annotations WG to review our document [recorded in
  <a href=
  "http://www.w3.org/2009/04/16-mediafrag-minutes.html#action07">http://www.w3.org/2009/04/16-mediafrag-minutes.html#action07</a>]<br />

  <strong>[NEW]</strong> <strong>ACTION:</strong> Yves to ask the
  TAG whether transcoding should be forbidden or not when we send a
  fragment of a resource [recorded in <a href=
  "http://www.w3.org/2009/04/16-mediafrag-minutes.html#action01">http://www.w3.org/2009/04/16-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: 2009/04/17 19:32:10 $
  </address>

</body>
</html>