17-mediafrag-minutes.html 38.1 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 -- 17 Sep
  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>- DRAFT -</h1>

  <h1>Media Fragments Working Group Teleconference</h1>

  <h2>17 Sep 2009</h2>

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

  <p>See also: <a href=
  "http://www.w3.org/2009/09/17-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, Michael, Raphael, Yves, Silvia, Franck_(irc),
      Jack_(irc), Conrad</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">Specification discussion</a></li>

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

        <li><a href="#item03">3. AOB</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: 17 September
    2009</p>

    <p class='irc'>&lt;<cite>scribe</cite>&gt; Meeting: Media
    Fragments Working Group 4th F2F Meeting (Virtual)</p>

    <h3 id="item01">Specification discussion</h3>

    <p class='phone'><cite>Erik:</cite> let's discuss first the
    aspect ratio issue</p>

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

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

    <p class='phone'><cite>Davy:</cite> in my opinion, the aspect
    is just another representation of the video, this is not a part
    of the video</p>

    <p class='phone'><cite>Yves:</cite> I barely agree with the
    fact that aspect is a different thing, but from the processing
    point of view, this is also something that requires
    transcoding<br />
    ... I'm happy to remove this use case if people are not
    comfortable with it</p>

    <p class='phone'><cite>Silvia:</cite> I just respond to Yves,
    this is the server who does the clipping, but I think that in
    the case of the ratio, the server should do nothing ... this is
    up to the client to add the black parts<br />
    ... so I see no reason for a use case, this is a presentation
    issue and not a fragment issue</p>

    <p class='irc'>&lt;<cite>franck</cite>&gt; hi all, will try to
    make the call (romm issue!)</p>

    <p class='phone'>PROPOSED RESOLUTION: take the aspect feature
    out of the spec and of our requirements</p>

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

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

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

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

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

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

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; +1 (and explain
    why in the doc)</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; apect ratio changes
    between what the server can provide and what the client wants
    to present are a presentation issue; one could either clip the
    video or add black bars; this should be up to the client to
    decide, not the server</p>

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

    <p class='phone'><strong class='resolution'>RESOLUTION: we
    agree that aspect ratio is not a fragment and will not be
    something that we can address with a Media Fragment
    URI</strong></p><a name="action01" id="action01"></a>

    <p class='irc'>&lt;<cite>scribe</cite>&gt;
    <strong>ACTION:</strong> Erik and Davy to write a paragraph in
    the documents to explain why we don't include this feature in
    the spec (rationale) based on the group analysis [recorded in
    <a href=
    "http://www.w3.org/2009/09/17-mediafrag-minutes.html#action01">http://www.w3.org/2009/09/17-mediafrag-minutes.html#action01</a>]</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; Created ACTION-109
    - And Davy to write a paragraph in the documents to explain why
    we don't include this feature in the spec (rationale) based on
    the group analysis [on Erik Mannens - due 2009-09-24].</p>

    <p class='phone'>Now, let's discuss the role of the ? vs #</p>

    <p class='phone'>Silvia summary: <a href=
    "http://blog.gingertech.net/2009/09/08/uri-fragments-vs-uri-queries-for-media-fragment-addressing/">
    http://blog.gingertech.net/2009/09/08/uri-fragments-vs-uri-queries-for-media-fragment-addressing/</a></p>

    <p class='phone'><cite>Silvia:</cite> I look at what Yves
    suggested, query and fragment are different depending on the
    need of trascoding or not<br />
    ... fragments, as it is defined currently, is something that
    needs to be resolved locally by the UA<br />
    ... any comments ?</p>

    <p class='phone'><cite>Michael:</cite> if we have transcoding,
    then URI queries should be used?</p>

    <p class='irc'>&lt;<cite>Gui</cite>&gt; I agree on
    differentiation # for client nav ? for server transcoding</p>

    <p class='phone'><cite>Silvia:</cite> yes to Michael
    question</p>

    <p class='phone'><cite>Michael:</cite> my only concern is the
    extra complexity introduced for the implementors</p>

    <p class='phone'><cite>Silvia:</cite> we are looking at various
    dimensions, we are pretty sure that for the temporal dimension,
    there will be often no transcoding required for most of the
    formats<br />
    ... so no problem<br />
    ... the problem will happen for the spatial dimension<br />
    ... where are not sure yet, when transcoding will be required ?
    always ?<br />
    ... I think therefore it is necessary to have solution for both
    cases when we need transcoding and we don't need</p>

    <p class='phone'><cite>Conrad:</cite> with /query/ we can
    always go back to the server, with fragments the UA has to do
    something</p>

    <p class='phone'><cite>Yves:</cite> conrad yes or no, yes if it
    receive the whole thing back, no if the server just send what's
    needed</p>

    <p class='phone'><cite>Silvia:</cite> look at the example I
    post today, everytime you click, it refresh the pages, this is
    very painful ...<br />
    ... this is what we want to change</p>

    <p class='irc'>&lt;<cite>Gui</cite>&gt; saw that. The
    clickthrough in the youtube example uses 2 separate videos that
    interlink each others</p>

    <p class='phone'>No Gui, see that <a href=
    "http://lists.w3.org/Archives/Public/public-media-fragment/2009Sep/0087.html">
    http://lists.w3.org/Archives/Public/public-media-fragment/2009Sep/0087.html</a></p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; Michael: I
    follow silvia's argumentation, though, for the sake of a simple
    standard I'd opt for # only</p>

    <p class='irc'>&lt;<cite>Gui</cite>&gt; Raphael, yes, that's
    the one I'm referring to. According to what I read, there were
    two similar looking videos involved to provide the linking
    effect for time offsetting.</p>

    <p class='phone'><cite>Raphael:</cite> my concern is then what
    will happen with the spatial dimension ... since it requires
    transcoding most of the time</p>

    <p class='phone'><cite>Yves:</cite> the whole document will be
    served<br />
    ... since the server cannot satisfy the range request</p>

    <p class='phone'><cite>Silvia:</cite> I agree</p>

    <p class='irc'>&lt;<cite>davy</cite>&gt; what about
    JPEG2000?</p>

    <p class='phone'><cite>Raphael:</cite> I have the feeling then
    that we are specifying a feature, #xhwh=100,100,400,400 that
    will never been satisfiable !</p>

    <p class='phone'>Davy argues that JPEG2000 might do it?</p>

    <p class='phone'><cite>Silvia:</cite> in the future, some
    codecs can do it ...</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; normal jpg can do this
    with block elvel as well, no?</p>

    <p class='phone'><cite>Silvia:</cite> I think this is not a new
    issue that comes up, we have discussed that a long time ago
    ...</p>

    <p class='phone'><cite>Raphael:</cite> we will need to document
    that, and particularly add many test cases, when the server
    needs to transcode to satisfy the range request</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I think what we have
    to do in our standard is to provide means for any kind of
    resource to allow creation of a media fragment URI that can
    request access to a fragment; some will be able to satisfy it
    from the local resource, others only with transcoding; thus we
    need to specify our addressing scheme for both possiblities: ?
    and #</p>

    <p class='phone'><cite>Yves:</cite> this is not an out of range
    case<br />
    ... this is something that is forbidden</p>

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

    <p class='phone'><cite>Yves:</cite> 416 is only used when it is
    possible to do a range request, but you have a out of bond
    case</p>

    <p class='irc'>&lt;<cite>Gui</cite>&gt; I agree with Silvia :
    "? AND #"</p>

    <p class='phone'><cite>Yves:</cite> here, we have something
    that cannot be applied<br />
    ... in the case of transcoding, the server will then must serve
    the whole content with a 200</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; I also agree that we
    need to define both ? and #</p>

    <p class='phone'><cite>Yves:</cite> so the server needs to
    identify whether transcoding is necessary or not, and then rely
    on the default HTTP rules</p>

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

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

    <p class='irc'>&lt;<cite>Gui</cite>&gt; ? and # 1. Gives more
    control to the user 2. Makes our syntax specification usable by
    current server side implementations</p>

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

    <p class='phone'><cite>Michael:</cite> I hesitate to make a big
    +1, because of the complexity<br />
    ... but I can live with it ... I would prefer to care about #
    now, and work on ? later on</p>

    <p class='phone'><cite>Davy:</cite> from an implementation
    point of view, I think the server has not a lot of extra
    work<br />
    ... the query thing comes almost for free when you implement
    the hash</p>

    <p class='phone'><cite>Michael:</cite> I'm thinking on both the
    UA and the server sides<br />
    ... principle thing, the more options you have, the more test
    cases and things to think about<br />
    ... but I understand the need and the arguments from the
    others</p>

    <p class='phone'><cite>Silvia:</cite> I think you're totally
    right, we don't want to add complexity we don't need<br />
    ... focus is on the hash, I see the ? as an optimization ...
    the communication aspect is already here anyway<br />
    ... for query, we need to specify nothing almost, this is
    already handled<br />
    ... in fact, we only specify the communication for the #, so to
    some extent you're ight<br />
    ... we are saying that the URI syntax can also be used for
    ?</p>

    <p class='phone'><cite>Michael:</cite> we are requiring that
    both are normative ? this is MUST or a SHOULD ?</p>

    <p class='phone'><cite>Silvia:</cite> the specification of a
    URL does not say anything about the implementation<br />
    ... we open the possibility to create URL in a standard
    format<br />
    ... correct me if I'm wrong, but I think we specify just the
    syntax of the URL and the way we should parse it<br />
    ... the hash resolution part must be normative</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; an implementation
    that claims to support # must do it this way</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; an implementation
    that claims to support ? must do it that way</p>

    <p class='irc'>&lt;<cite>Gui</cite>&gt; ? and # - 3. Also
    precise if the user wants data in or out of context ?</p>

    <p class='phone'><cite>Silvia:</cite> for the query, we could
    suggest to use the same way</p>

    <p class='phone'><cite>Michael:</cite> if this is not
    normative, does that have an incident on interoperability<br />
    ... are we after a MUST or a SHOULD?</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; i suggest that an
    implementation must state what it claims to support (eg.
    through http headers, uri parameters or whatever) -- and if it
    makes that claim, it must do it as described</p>

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

    <p class='phone'><cite>Michael:</cite> in the case of ?, I
    think the MUST is a strong constraint</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; whereas if it
    doesn't make that claim (eg. all existing urls) then this
    standard does not apply</p>

    <p class='phone'><cite>Raphael:</cite> I'm well aware of the
    terminology</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; we specify a MUST on
    the method of advertising that this standard applies to this
    URL</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; as conrad says: if I
    claim conformance, I must follow the protocol - otherwise the
    communication cannot be resolved</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; we need to specify
    how conformance is claimed</p>

    <p class='phone'><cite>Michael:</cite> am I the only one who
    doesn't really get what will be specified normatively in the
    case of the ?</p>

    <p class='phone'><cite>Silvia:</cite> are you talking about the
    communication between the UA and the server ?</p>

    <p class='irc'>&lt;<cite>FD</cite>&gt; when using query '?' you
    may have to specify the communication to get context info (Link
    header for example)</p>

    <p class='phone'><cite>Raphael:</cite> oups, you're right
    Frank, thanks for the heads up :-)</p>

    <p class='phone'><cite>Frank:</cite> I just wanted to remember
    the point of using the link header in the response of the
    server ... so the UA gets the context of the parent
    resource</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; Frank, can you
    please be more specific? Are you referring to LRDD?</p>

    <p class='phone'><cite>Silvia:</cite> are you suggesting we
    write a MAY use instead of a MUST use?</p>

    <p class='irc'>&lt;<cite>Gui</cite>&gt; Is the difference
    between ? and # introduce a difference between secondary
    resource and a derived resource?</p>

    <p class='phone'><cite>Frank:</cite> I have no precise idea of
    how the link header semantics should be used</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; I agree with
    Frank. Context should be done via LRDD (<a href=
    "http://tools.ietf.org/html/draft-hammer-discovery-03)">http://tools.ietf.org/html/draft-hammer-discovery-03)</a></p>

    <p class='phone'><cite>Frank:</cite> but the communication
    between the server and the UA must be alterated because of the
    addition of the link header</p>

    <p class='phone'><cite>Yves:</cite> for me, the link header
    should always be used in the query case<br />
    ... we could mandate that<br />
    ... I don't think there is a current property / value for that
    already, we might look for it<br />
    ... invent a part-of ?</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; i think the link
    header is useful, but should not be MUST</p>

    <p class='phone'><cite>Yves:</cite> perhaps there is already
    something already</p>

    <p class='phone'><cite>Michael:</cite> LRDD specifies the
    semantics for relating a resource and its description via
    describedBy for three cases (link element, Link: header, and
    well-known location)</p>

    <p class='phone'><cite>Yves:</cite> we may have a separate RFC
    for that ...</p>

    <p class='phone'><cite>Michael:</cite> problem of timeline, it
    will be ready on time ?</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I agree with conrad
    - if the resource has all the information about the offsetting
    etc inside it, it doesn't need to be accompanied by parent
    information</p>

    <p class='phone'><cite>Yves:</cite> I don't exactly when the
    RFC will be ready ... but I believe the time frame is
    correct</p>

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

    <p class='irc'>&lt;<cite>Yves</cite>&gt; <a href=
    "http://www.mnot.net/drafts/draft-nottingham-http-link-header-07.txt">
    http://www.mnot.net/drafts/draft-nottingham-http-link-header-07.txt</a></p>

    <p class='phone'><cite>Conrad:</cite> I think the header is
    useful, but why mandating to send the whole context ?</p>

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

    <p class='irc'>&lt;<cite>FD</cite>&gt; Agree with Conrad,
    required mainly for display/clipping</p>

    <p class='phone'><cite>Raphael:</cite> time to summarize ...
    who wants to give it a try?</p>

    <p class='phone'>[silence]</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; isn't the summary
    that both are useful in different situations?</p>

    <p class='phone'>[dead silence]</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; resolution draft: we
    agree that there is a need for allowing both a ? and a #
    specification for media fragments</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; we further agree
    that our main focus is #, but that the communication that we
    define between client and server will be adapted also to the ?
    case</p>

    <p class='phone'><cite>Michael:</cite> I still have a
    question<br />
    ... what's happen when there is both ? there is a hierarchy,
    query first and then fragment</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; such that for media
    fragment URIs that cannot be resolved with # because it needs
    transcoding, ? can be used</p>

    <p class='phone'><cite>Michael:</cite> what's happen when:
    ?t=10,30#15</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; the ? defines a URL,
    the # is a relative offset</p>

    <p class='phone'><cite>Silvia:</cite> I think this is obvious
    to what happens ...<br />
    ... the query generates a new resource, and the fragment is a
    new relative offset to this new resource<br />
    ... in raphael's case, it will start at 25s</p>

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

    <p class='irc'>&lt;<cite>Gui</cite>&gt; +1 that makes sense</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; since a URI with a ?
    part creates a new resource, we have to do the fragment offset
    on the new resource, which in this case means it will start at
    25s</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; +1 to the
    proposal. I'm fine with silvia's explanation</p>

    <p class='phone'><cite>Raphael:</cite> our starting point is
    <a href=
    "http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#fragment-query">
    http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#fragment-query</a></p>

    <p class='phone'><cite>Silvia:</cite> does someone have any
    issue in my blog post?<br />
    ... if not, then we can give an action to someone to draft a
    good exaplanation based on my post and this discussion on
    irc</p>

    <p class='phone'><cite>Michael:</cite> wondering if there is a
    type in silvia's example at <a href=
    "http://blog.gingertech.net/2009/09/08/uri-fragments-vs-uri-queries-for-media-fragment-addressing/">
    http://blog.gingertech.net/2009/09/08/uri-fragments-vs-uri-queries-for-media-fragment-addressing/</a><br />

    ... Range: seconds=20- and then Content-Range: seconds
    11.85-21.16/3600<br />
    ... shouldn't this be seconds=12- ...?</p>

    <p class='phone'><cite>Silvia:</cite> no, the server works in a
    best effort<br />
    ... I am trying to explain that content may not be able to be
    resolved to the required resolution depending on the
    codec<br />
    ... this is an example of what a server might only be able to
    do ...<br />
    ... as a server, you ask for a time range, but I can only serve
    you that, and then the UA needs to throw away what's in
    extra<br />
    ... no way of doing that differently, since the UA will not be
    able to decode it otherwise</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; the client requests
    t=20, the previous keyframe is t=12 so the server sends from
    there</p>

    <p class='phone'>Raphael; this 8s is odd :-) there are more
    I-Frames in the middle :-)</p>

    <p class='phone'><cite>Michael:</cite> I'm just suggesting
    there is a typo</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; ignore my keyframe
    explanation here :)</p>

    <p class='irc'>&lt;<cite>davy</cite>&gt; check apple movie
    trailers: very few I Frames ...</p>

    <p class='phone'><cite>Silvia:</cite> the remaining of the post
    talks about the headers, but this is for next half of the
    meeting</p>

    <p class='irc'>&lt;<cite>erik</cite>&gt; one thing at the
    time</p>

    <p class='phone'><cite>Michael:</cite> my guess is that Silvia
    is the best volunteer to draft the summary</p>

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

    <p class='irc'>&lt;<cite>conrad</cite>&gt; zakim unmute
    me</p><a name="action02" id="action02"></a>

    <p class='irc'>&lt;<cite>scribe</cite>&gt;
    <strong>ACTION:</strong> Silvia to draft a summary starting
    from her blog post and these IRC minutes in the document
    [recorded in <a href=
    "http://www.w3.org/2009/09/17-mediafrag-minutes.html#action02">http://www.w3.org/2009/09/17-mediafrag-minutes.html#action02</a>]</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; Created ACTION-110
    - Draft a summary starting from her blog post and these IRC
    minutes in the document [on Silvia Pfeiffer - due
    2009-09-24].</p>

    <h3 id="item02">2. Protocol discussion</h3>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; ACTION-69?</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; ACTION-69 --
    Conrad Parker to draw a representation of the general structure
    of a media resource, for streamable formats (H/H' + K + D1 + D2
    + D3) -- due 2009-04-24 -- OPEN</p>

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

    <p class='phone'><cite>Conrad:</cite> I wanted to describe how
    ogg files are structured<br />
    ... and if one is a sub part of another, then which parts
    changed or not</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; if you have an
    original file H D1 D2 D3</p>

    <p class='phone'><cite>Raphael:</cite> is this drawing
    available somewhere ?</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; and you make a
    subview that goes H' D2 D3</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; raphael - no,
    it is not available, hence my comment</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; Michael: I
    think conrad needs to draw it (even just with pencil and scan
    it in - and we postpone it to tomorrow ...)</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; with keyframes, you
    might end up with something like H' D2' D3</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; I'd also like to
    point out that different containers/codecs work differently and
    have different challenges</p>

    <p class='phone'><cite>Conrad:</cite> I will draw it tonight,
    postpone the visualization tomorrow morning</p>

    <p class='phone'><cite>Raphael:</cite> two more things to
    discuss, headers and range syntax<br />
    ... should we start with the Range syntax ?</p>

    <p class='phone'>[silence]</p>

    <p class='phone'>Yves's proposal: <a href=
    "http://lists.w3.org/Archives/Public/public-media-fragment/2009Sep/0035.html">
    http://lists.w3.org/Archives/Public/public-media-fragment/2009Sep/0035.html</a></p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; let's not mix
    formats</p>

    <p class='phone'>Yves made 2 suggestions</p>

    <p class='phone'><cite>scribe:</cite> 1: unit and then
    values<br />
    ... 2: unit can be mixed</p>

    <p class='phone'><cite>Michael:</cite> second option seems more
    complex</p>

    <p class='phone'><cite>Raphael:</cite> we don't need to mix
    units, anyway, the URI syntax does not permit it</p>

    <p class='phone'>Yves proposal just concerns the time dimension
    ... more issue with other dimensions</p>

    <p class='phone'><cite>Frank:</cite> what will be the duration
    of the track dimension?</p>

    <p class='irc'>&lt;<cite>mhausenblas</cite>&gt; Michael: track
    and ID do not have dimensions</p>

    <p class='phone'><cite>Michael:</cite> track is identified by a
    name, full stop</p>

    <p class='phone'><cite>Raphael:</cite> is track and id a Range
    request?<br />
    ... if yes, then what is the Content Range ?<br />
    ... if this is: Content-Range: track 'video' / what is behind
    the '/' ?</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; you could talk about
    the number of labels</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; track does not
    belong in Range</p>

    <p class='irc'>&lt;<cite>erik</cite>&gt; rssagent, draft
    minutes</p>

    <p class='phone'><cite>Silvia:</cite> yes, good point from
    Conrad, why does he think track and id are not range
    request?</p>

    <p class='phone'><cite>Conrad:</cite> I think a track is not
    something one can see as a range</p>

    <p class='irc'>&lt;<cite>Gui</cite>&gt; Track is not a time
    range, at best, Track is a Byte range which correspond to this
    piece of the media only holding the track, at worste, its muxed
    and interleaved and has no range</p>

    <p class='phone'><cite>Conrad:</cite> i admit, tricky issue</p>

    <p class='irc'>&lt;<cite>Zakim</cite>&gt; mhausenblas, you
    wanted to talk about orthogonal addressing concept continuos
    (time/spatial) and discrete (track/ID)</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; range should be for
    continuous addressing</p>

    <p class='phone'><cite>Raphael:</cite> Guillaume, we are not
    talking about time range ... but range request, expressed in
    bytes or other units</p>

    <p class='phone'><cite>Michael:</cite> Orthogonal addressing
    concepts: time / spatial (continuous) vs track / id
    (discrete)</p>

    <p class='phone'><cite>Raphael:</cite> I would say "id" is even
    different, since this is a combination of the others<br />
    ... I would put id aside</p>

    <p class='irc'>&lt;<cite>Gui</cite>&gt; raphael: I was
    answering to michael mentioning that track COULD be a time
    range, and I think it just can't</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; you can't define a
    distance metric over track ;-)</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; so do we need
    different mechanisms to resolve id and track?</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; so this is why i was
    suggesting a Fragment header</p>

    <p class='irc'>&lt;<cite>Gui</cite>&gt; Michael &amp; Raphael :
    Ok</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; maybe track can only
    ever be used with ?</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; <a href=
    "http://www.w3.org/2008/WebVideo/Fragments/wiki/Server-parsed_Fragments">
    http://www.w3.org/2008/WebVideo/Fragments/wiki/Server-parsed_Fragments</a></p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; <a href=
    "http://www.w3.org/2008/WebVideo/Fragments/wiki/HTTP_Examples#Track.2BTime_Fragment_URI">
    http://www.w3.org/2008/WebVideo/Fragments/wiki/HTTP_Examples#Track.2BTime_Fragment_URI</a></p>

    <p class='irc'>&lt;<cite>Gui</cite>&gt; There is a case where
    what's behind the track video / 1 could be an index in case
    many audio or video tracks</p>

    <p class='phone'><cite>Silvia:</cite> when we started to talk
    about fragments, we were talking about continous set of
    bytes<br />
    ... for temporal, it was a reasonable assumption<br />
    ... for spatial, it starts to be a problem in most of the
    coding format<br />
    ... for track, as Conrad said, it is difficult<br />
    ... is it a case of transcoding that can be resolved only with
    transcoding ?</p>

    <p class='irc'>&lt;<cite>davy</cite>&gt; if an adaptation can
    be expressed in terms of byte ranges, it is not transcoding</p>

    <p class='phone'><cite>Silvia:</cite> I'm not sure about that
    either ... I'm very uncertain so far, I need to make my
    mind</p>

    <p class='phone'><cite>Michael:</cite> I'm afraid we are
    introducing something too complex with the ID concept; track
    might be sufficient</p>

    <p class='phone'><cite>Raphael:</cite> accessibility is the
    main use case for tracks and it is very important</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; a track request
    without transcoding may result in thousands of byte ranges for
    concatenation</p>

    <p class='phone'><cite>Silvia:</cite> our focus is on time ...
    this needs to get more thoughts</p>

    <p class='irc'>&lt;<cite>Gui</cite>&gt; Gui agrees with
    Conrad</p>

    <p class='irc'>&lt;<cite>davy</cite>&gt; what's wrong with that
    if the server joines these byte ranges?</p>

    <p class='phone'><cite>Raphael:</cite> expectation is to have a
    2nd WD ready by the end of the month to be published</p>

    <p class='phone'><cite>Silvia:</cite> would suggest to focus on
    temporal domain for this next version of the WD, such that
    people can start using it - the browser vendors and HTML5 are
    keen to get into it</p>

    <p class='phone'><cite>Davy:</cite> I don't think this is an
    issue for the server to do the join of the bytes ranges and
    serve the joint part</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; davy, yes, that case
    is not an issue</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; for this resolution
    we would need to specify an exact set of range names</p>

    <p class='phone'><cite>Raphael:</cite> time for
    resolution<br />
    ... I see 2 proposals on the table<br />
    ... Proposal 1: Content-Range &lt;timeformat&gt; ' ' &lt;real
    start time&gt; '-' &lt;real end time&gt; '/' &lt;total
    duration&gt;<br />
    ... actually, &lt;timeformat&gt; is &lt;unit&gt;<br />
    ... Proposal 2: Content-Range &lt;dimension&gt; ':'
    &lt;unit&gt; ' ' &lt;real start time&gt; '-' &lt;real end
    time&gt; '/' &lt;total duration&gt;</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; no quite - this is
    correct for proposal 2: Content-Range: time:&lt;timeformat&gt;
    ' ' &lt;real start time&gt; '-' &lt;real end time&gt; '/'
    &lt;total duration&gt;</p>

    <p class='phone'><cite>Raphael:</cite> in the second proposal,
    &lt;dimension&gt; will be 'time', 'xywh', etc.</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; yeah, but &lt;total
    duration&gt; may change depending on the &lt;unit&gt;</p>

    <p class='phone'><cite>Raphael:</cite> what is the added value
    of having the dimension ?<br />
    ... smpte unit means we are in the time dimension, no confusion
    possible</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; the value of
    specifying dimension is to simplify the standardization</p>

    <p class='phone'><cite>Silvia:</cite> it is more readable, and
    the total duration can be unit dependent and NOT unit
    dependent</p>

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

    <p class='irc'>&lt;<cite>conrad</cite>&gt; ie. "the advantage
    of being more flexible, but less robust to the introduction of
    new units"</p>

    <p class='phone'><cite>Erik:</cite> the proposal 2 here is NOT
    the proposal 2 of Yves<br />
    ... Proposal 2 is an amendment from Silvia from Proposal 1 from
    Yves</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; advantages as I see
    them: (1) can use default unit per dimension with only
    dimension (2) can be more easily extended with new units since
    &lt;total duration&gt; won't change (3) is more like url
    specification</p>

    <p class='irc'>&lt;<cite>conrad</cite>&gt; if the duration
    includes a frameno it is timeformat dependent</p>

    <p class='phone'>correct conrad</p>

    <p class='phone'><cite>Silvia:</cite> &lt;total duration&gt; is
    not correct<br />
    ... we need to be more generic</p>

    <p class='irc'>&lt;<cite>FD</cite>&gt; Rename &lt;total
    duration&gt; into &lt;total-dimension&gt; ?</p>

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

    <p class='irc'>&lt;<cite>silvia</cite>&gt; Proposal 2:
    Content-Range &lt;dimension&gt; [':' &lt;unit&gt;] ' ' &lt;real
    start time&gt; '-' &lt;real end time&gt; '/' &lt;total
    dimension&gt;</p>

    <p class='irc'>&lt;<cite>erik</cite>&gt; +1 to Silvia's
    "Proposal 2" here</p>

    <p class='phone'>PROPOSED RESOLUTION: Content-Range
    &lt;dimension&gt; [':' &lt;unit&gt;] ' ' &lt;real start
    time&gt; '-' &lt;real end time&gt; '/' &lt;total
    dimension&gt;</p>

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

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

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

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

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

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

    <p class='irc'>&lt;<cite>Gui</cite>&gt; looking</p>

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

    <p class='phone'><strong class='resolution'>RESOLUTION:
    Content-Range &lt;dimension&gt; [':' &lt;unit&gt;] ' ' &lt;real
    start time&gt; '-' &lt;real end time&gt; '/' &lt;total
    dimension&gt; is the syntax to be used for a Range Request for
    the temporal dimension</strong></p>

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

    <p class='irc'>&lt;<cite>Gui</cite>&gt; great!</p>

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

    <p class='irc'>&lt;<cite>FD</cite>&gt; not only temporal!</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; well, we have to see
    if it works for all dimensions</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; right now we're sure
    it works for time</p>

    <h3 id="item03">3. AOB</h3>

    <p class='irc'>&lt;<cite>FD</cite>&gt; I think &lt;real start
    time&gt; and &lt;real end time&gt; should also be
    generalized</p>

    <p class='irc'>&lt;<cite>silvia</cite>&gt; FD, so right!</p>

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

    <p class='phone'>Thanks all for the engagement</p>

    <p class='irc'>&lt;<cite>FD</cite>&gt; quit</p>

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

    <p class='irc'>&lt;<cite>erik</cite>&gt; rssagent, draft
    minutes</p>

    <p class='phone'><cite>scribe:</cite> I wish we have the same
    productivity tomorrow morning</p>
  </div>

  <h2><a name="ActionSummary" id="ActionSummary">Summary of Action
  Items</a></h2><!-- Action Items -->
  <strong>[NEW]</strong> <strong>ACTION:</strong> Erik and Davy to
  write a paragraph in the documents to explain why we don't
  include this feature in the spec (rationale) based on the group
  analysis [recorded in <a href=
  "http://www.w3.org/2009/09/17-mediafrag-minutes.html#action01">http://www.w3.org/2009/09/17-mediafrag-minutes.html#action01</a>]<br />

  <strong>[NEW]</strong> <strong>ACTION:</strong> Silvia to draft a
  summary starting from her blog post and these IRC minutes in the
  document [recorded in <a href=
  "http://www.w3.org/2009/09/17-mediafrag-minutes.html#action02">http://www.w3.org/2009/09/17-mediafrag-minutes.html#action02</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/09/17 10:03:42 $
  </address>

  <div class="diagnostics">
    <hr />

    <h2>Scribe.perl diagnostic output</h2>[Delete this section
    before finalizing the minutes.]<br />
    <pre>
This is scribe.perl Revision: 1.135  of Date: 2009/03/02 03:52:20
Check for newer version at <a href=
"http://dev.w3.org/cvsweb/~checkout~/2002/scribe/">http://dev.w3.org/cvsweb/~checkout~/2002/scribe/</a>

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/anyways/anyway/
Succeeded: s/LRDD specifies only [to complete]/LRDD specifies the semantics for relating a resource and its description via describedBy for three cases (link element, Link: header, and well-known location)/
Succeeded: s/type/typo/
Succeeded: s/suggestion/suggesting/
Succeeded: s/comple/complex/
Succeeded: s/something too complex/something too complex with the ID concept; track might be sufficient/
Succeeded: s/genreic/generic/
Found Scribe: raphael
Inferring ScribeNick: raphael
Found ScribeNick: raphael
Default Present: +0329331aaaa, mhausenblas, +61.2.801.2.aabb, raphael, silvia, erik, Yves, +2712841aacc, Gui, tmichel, conrad, +aadd, FD
Present: Davy Erik Michael Raphael Yves Silvia Franck_(irc) Jack_(irc) Conrad
Agenda: <a href=
"http://www.w3.org/2008/WebVideo/Fragments/wiki/FourthF2FAgenda">http://www.w3.org/2008/WebVideo/Fragments/wiki/FourthF2FAgenda</a>
Found Date: 17 Sep 2009
Guessing minutes URL: <a href=
"http://www.w3.org/2009/09/17-mediafrag-minutes.html">http://www.w3.org/2009/09/17-mediafrag-minutes.html</a>
People with action items: davy erik silvia

</pre>[End of <a href=
"http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm">
    scribe.perl</a> diagnostic output]
  </div>
</body>
</html>