21-mediafrag-minutes.html 31 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 -- 21 Oct
  2008</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>21 Oct 2008</h2>

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

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

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

      <dd>Erik, Davy, Yves, Guillaume, Silvia, Raphael, Colm_Doyle,
      Fons_Kuijk, Jack, Frank</dd>

      <dt>Regrets</dt>

      <dt>Chair</dt>

      <dd>Erik, Raphael</dd>

      <dt>Scribe</dt>

      <dd>Erik</dd>
    </dl>
  </div>

  <h2>Contents</h2>

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

      <ol>
        <li><a href="#item01">Issues</a></li>

        <li><a href="#item02">URI Fragment / URI Query</a></li>

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

        <li><a href="#item04">URI Fragment / URI Query</a></li>

        <li><a href="#item05">Fragment Name and
        Description</a></li>

        <li><a href="#item06">Status of a Media Fragment</a></li>

        <li><a href="#item07">Server, Cache and Proxies</a></li>

        <li><a href="#item08">Protocols</a></li>

        <li><a href="#item09">Wrap-up</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>raphael</cite>&gt; trackbot, start
    telcon</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; Date: 21 October
    2008</p>

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

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

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

    <h3 id="item01">Issues</h3>

    <p class='phone'>1. Continuity/Discontinuity</p>

    <p class='phone'><cite>silvia:</cite> URI-scheme could cover
    multi-part (if needed)</p>

    <p class='phone'>silvia/jack: if multiple fragments in one URL,
    hierarchy structure could be problem ... SMIL can do that</p>

    <p class='phone'><cite>jack:</cite> something for v2?</p>

    <p class='phone'><cite>raphael:</cite> still a lot of issues,
    postpone a bit</p>

    <p class='phone'><cite>jack:</cite> will influence syntax
    somehow pretty soon</p>

    <p class='phone'>conclusion for continuity/discontinuity:
    postponed a bit, but keep in mind</p>

    <p class='phone'>2. spatial fragment shape</p>

    <p class='phone'><cite>jack:</cite> non-rectangular shape is
    only important if animation is also covered</p>

    <p class='phone'>silvia/davy/erik: rectangular is most
    feasable, most important, easiest to implement</p>

    <p class='phone'><cite>raphael:</cite> we should look at what
    SVG-group did</p>

    <p class='phone'>conclusion for spatial fragment shape:
    rectangular shape to start with</p>

    <p class='phone'>silvia/jack: non-rectangular shapes on images
    are do-able, but for video rectangular is only valid use
    case</p>

    <p class='phone'>3. container &amp; substreams</p>

    <p class='phone'><cite>silvia:</cite> container formats are
    enough to consider</p>

    <p class='phone'><cite>jack:</cite> is there any important
    codecs/containers missing?</p>

    <p class='phone'>davy explains codecs wiki-page</p>

    <p class='phone'><cite>silvia:</cite> should also add SNOW
    (wavelet based) from FFMPEG</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; <a href=
    "http://svn.mplayerhq.hu/ffmpeg/trunk/doc/snow.txt?view=co">http://svn.mplayerhq.hu/ffmpeg/trunk/doc/snow.txt?view=co</a></p>

    <p class='phone'><cite>silvia:</cite> also in audio codecs
    framing is not deterministic</p>

    <p class='phone'><cite>davy:</cite> but more easy to jump into
    audio than it is to jump into video</p>

    <p class='phone'><cite>silvia:</cite> MPEG-1 has different
    kinds of encapsulation, good to have but more difficult to
    handle<br />
    ... only make assumption about general structure of resource
    (not about coding &amp; decoding)<br />
    ... FLAC is already framed</p>

    <p class='phone'>Erik will update codec page ... including
    SNOW, AVS, SVC, OMS, Speex, MLP</p>

    <p class='phone'><cite>Silvia:</cite> raw formats are even
    easier to handle then codecs</p>

    <p class='phone'>davy explains container wiki-page</p>

    <p class='irc'>&lt;<cite>guillaume</cite>&gt; raw "WAV" or
    "YUV" have a more direct / linear time to byte mapping</p>

    <p class='phone'>erik/davy to check if .mp4 can have references
    to other files as indexing could be more complex</p>

    <p class='phone'>davy/jack/raphael: player that doesn't
    understand some "boxes", probably will skip it and play what it
    understands</p>

    <p class='phone'><cite>jack:</cite> what about encrypted
    AAC?</p>

    <p class='phone'><cite>silvia:</cite> DRM is another
    ballgame</p>

    <p class='phone'><cite>raphael:</cite> we will mention the
    limitations of our solutions (cfr. DRM-stuff)</p>

    <p class='phone'><cite>silvia:</cite> within OGG you always
    need the header instead of mp3 for example</p>

    <p class='phone'>erik/davy will update container wiki-page ...
    adding AU, XVID, DIVX &amp; check consistency with media
    resource model of silvia</p>

    <p class='phone'><cite>silvia:</cite> substreams are just
    another point of view of fragments adressing<br />
    ... solve spatial &amp; temporal adressing issue, but see that
    it is extendable (generic scheme) for e.g. substreams<br />
    ... create a syntax spec. that is extensible</p>

    <p class='phone'><cite>jack:</cite> certainly keep that in mind
    when talking about syntax starts</p>

    <p class='phone'>conclusion of substreams (e.g. tracks, ...):
    postpone decision, but certainly create syntax that is
    extensible to incorporate this at a later time</p>

    <p class='phone'>4. in-context vs. out-of-context</p>

    <p class='phone'><cite>jack:</cite> only jump to specific
    "paragraph" in isolation or jump to "paragraph" in context of
    whole document</p>

    <p class='phone'><cite>silvia:</cite> just an application
    issue</p>

    <p class='phone'><cite>yves:</cite> applications should be
    independant of our addressing scheme</p>

    <p class='phone'><cite>raphael:</cite> fragment point of view
    ... context awareness<br />
    ... application point of view ... should be context independant
    according to the addressing scheme</p>

    <p class='phone'><cite>yves:</cite> implementation should be
    able to choose (as in browsers nowadays)</p>

    <p class='irc'>&lt;<cite>raphael</cite>&gt; Example of a bad
    fragment: <a href=
    "http://www.techcrunch.com/2008/10/10/getting-the-unparty-started-seesmic-lays-off-13-of-staff/">
    http://www.techcrunch.com/2008/10/10/getting-the-unparty-started-seesmic-lays-off-13-of-staff/</a></p>

    <p class='phone'>conclusion of in-context vs. out-of-context:
    we want to make sure that fragment is aware of "full"
    resource</p>

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

    <p class='phone'>TOPICS: URI Fragment / URI Query</p>

    <h3 id="item02">URI Fragment / URI Query</h3>

    <p class='phone'>Yves drawing on the board</p>

    <p class='phone'><cite>scribe:</cite> User requests <a href=
    "http://www.example.com/foo#t=1">http://www.example.com/foo#t=1</a>,20<br />

    ... UA is smart, knows that the URI without the hash part will
    be sent to the server<br />
    ... UA can ask in the local hhtp cache if the resource is
    here<br />
    ... it requires the browser vendors do some clever things with
    the hash part<br />
    ... browsers do that already with an XPATH expression after the
    #</p>

    <p class='phone'><cite>Jack:</cite> difference is here that
    browsers do that before sending to the server the request of
    the resources, so browsers have no clue what is the mime type
    of the resource</p>

    <p class='phone'><cite>Yves:</cite> case 1 = Base URI is a
    video<br />
    ... send a range request: second 1-20<br />
    ... server sends back a content range: second 1-20 + the
    content type<br />
    ... no need of the four-way handshake?</p>

    <p class='phone'><cite>Silvia:</cite> I have a pretty big
    problem, because of the possibility of caching the fragments in
    the proxies</p>

    <p class='phone'><cite>Yves:</cite> we would need dedicated
    video proxies<br />
    ... that understand seconds?<br />
    ... the proxies will be able to cache it<br />
    ... case 2 = Base URI is text<br />
    ... the range unit cannot be applied to the resource<br />
    ... the server will provide the right content header and the
    resource<br />
    ... in this case, the UA will seek to the id = 't=1,20' of the
    text resource</p>

    <p class='phone'><cite>Jack:</cite> put garbage behind the #
    ... the UA wil display the all resource</p>

    <p class='phone'><cite>Yves:</cite> case 3 = Base URI is a
    video<br />
    ... the server does not know how to handle range request with
    seconds<br />
    ... will send the whole resource</p>

    <p class='phone'><cite>Raphael:</cite> we can in this case do a
    4-way handshake</p>

    <p class='phone'><cite>Yves:</cite> case 4 = Base URI is a text
    on an old fashioned web server<br />
    ... works as in case 2</p>

    <p class='phone'>This solution is a mix between a 2-way and a
    4-way handshake</p>

    <p class='phone'><cite>Jack:</cite> how the case 3 works with a
    old fashioned web server</p>

    <p class='phone'><cite>Yves:</cite> we can have services on
    proxy, that will do the work, i.e. do the cropping<br />
    ... in the worst case, the whole video is sent</p>

    <p class='phone'><cite>Jack:</cite> what about adding http
    extra headers?</p>

    <p class='phone'><cite>Yves:</cite> adding extra http headers
    will make old fashioned web servers ignoring them<br />
    ... http is a 'must ignored'<br />
    ... does not break previous implementations</p>

    <p class='irc'>&lt;<cite>guillaume</cite>&gt; Jack: Couldn't we
    have a "must understand"?</p>

    <p class='irc'>&lt;<cite>erik</cite>&gt; Jack: our addressing
    scheme should come up with half of the solution, the other half
    should come from HTTP (or other) protocol</p>

    <p class='phone'><cite>Silvia:</cite> look at the HTTP/1.1,
    RFC2616, sec 10.4.17 ... 416 Requested Range Not
    Satisfiable</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; <a href=
    "http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.17">
    http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.17</a></p>

    <p class='phone'><cite>Silvia:</cite> we didn't consider that
    in TemporalURI since we assumed we will not change the
    browsers</p>

    <p class='phone'><cite>Yves:</cite> not that a problem to
    change the browsers</p>

    <p class='phone'><cite>Jack:</cite> are the browser vendors the
    only people we want to talk</p>

    <p class='phone'><cite>Yves:</cite> browsers, media players,
    proxies such as Squid<br />
    ... we need to talk to all of them<br />
    ... TAG will be happy because we are making a good use of the
    '#'<br />
    ... I'm editor of HTTP 1.1 bis in IETF</p>

    <p class='phone'><cite>Sivlia:</cite> I want to dig how we can
    implement this solution<br />
    ... look at the RFC2396, section 4: URI References</p>

    <p class='irc'>&lt;<cite>nessy</cite>&gt; <a href=
    "http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3986.txt</a></p>

    <p class='phone'><cite>Sivlia:</cite> again a way of encoding
    the mime-type of the resource in the fragment scheme</p>

    <p class='phone'><cite>Jack:</cite> Larry said yesterday that
    who owns the mime-type owns the def of fragment of a
    resource</p>

    <p class='phone'><cite>Silvia:</cite> Read the section 4 of
    RFC3986 !!! the new one<br />
    ... the fragment is never sent to the network<br />
    ... oups, read the section 3.5 !!!</p>

    <p class='phone'><cite>raphael:</cite> wonders if we link to
    the good URI in the wiki !!! Need to check</p>

    <p class='phone'><cite>Silvia:</cite> how can we define the
    mime-type implicitely in the URI scheme</p>

    <p class='phone'><cite>All:</cite> problem, is the '(' allowed
    in a fragment of a textual document?</p>

    <p class='phone'><cite>Jack:</cite> then the construct
    xpath(...) would have a problem</p>

    <p class='phone'><cite>Silvia:</cite> check, parenthesis is not
    allowed<br />
    ... so the mf() scheme of MPEG-21 is fine, as well as the XPATH
    scheme<br />
    ... we could use the same trick<br />
    ... Possible syntax: #fragment(..., ..., ...) and a comma
    separated list</p>

    <p class='phone'><cite>Jack:</cite> of course this will be a
    functional notation</p>

    <p class='phone'><cite>Silvia:</cite> can also use the '&amp;'
    as it is done in cgi, and we can concatenate as many as we want
    parameters<br />
    ... we need to have a discussion whether a fragment is a
    function or not</p>

    <p class='phone'><cite>Jack:</cite> if want to be extensible,
    we would need to have a sort of functional syntax</p>

    <p class='phone'><cite>Silvia:</cite> keep it simple should be
    the motto<br />
    ... that might throw away the multi-fragments functionality</p>

    <p class='phone'><cite>Jack:</cite> we think our projection on
    the time/space/track axes are commutative, all the parameters
    can be applied in any order<br />
    ... if this is the case, we can have a flat list parameter =
    value and we do not need a functional syntax<br />
    ... do we agree on that ?</p>

    <p class='phone'><cite>Guillaume:</cite> I don't ...</p>

    <p class='phone'><cite>Silvia:</cite> in the case of a
    non-functional notation, I would like to have the first
    character giving an hint to the UA which kind of resources we
    are dealing with<br />
    ... I would recommend to give the very first character to do
    that</p>

    <p class='phone'><cite>Yves:</cite> it won't work<br />
    ... anybody can do the same<br />
    ... SVG is both image and text</p>

    <p class='phone'><cite>Silvia:</cite> let's reformulate: I
    would put the very first character to distinguish between an
    HTML resource or non-HTML resource<br />
    ... I would avoid to have '(' and ')' because it implies
    functional notation<br />
    ... we could use ':'</p>

    <p class='phone'><cite>Yves:</cite> this is syntax ... it is
    not important</p>

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

    <p class='phone'><cite>Erik:</cite> Weekly teleconference, day
    and hour</p>

    <p class='phone'><cite>Proposal:</cite> have the weekly telecon
    on Wednesday, 10:00 AM UTC<br />
    ... from now on ... until we get someone from the US West coast
    in the group<br />
    ... have the weekly telecon on Wednesday, 09:30 AM UTC</p>

    <p class='phone'><a href=
    "http://www.timeanddate.com/worldclock/fixedtime.html?day=05&amp;month=11&amp;year=2008&amp;hour=09&amp;min=30&amp;sec=0&amp;p1=0">
    http://www.timeanddate.com/worldclock/fixedtime.html?day=05&amp;month=11&amp;year=2008&amp;hour=09&amp;min=30&amp;sec=0&amp;p1=0</a></p>

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

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

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

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

    <p class='irc'>&lt;<cite>guillaume</cite>&gt; +1</p><a name=
    "action01" id="action01"></a>

    <p class='irc'>&lt;<cite>scribe</cite>&gt;
    <strong>ACTION:</strong> Yves to request a new time slot on the
    Zakim bridge [recorded in <a href=
    "http://www.w3.org/2008/10/21-mediafrag-minutes.html#action01">http://www.w3.org/2008/10/21-mediafrag-minutes.html#action01</a>]</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; Created ACTION-7 -
    Request a new time slot on the Zakim bridge [on Yves Lafon -
    due 2008-10-28].</p>

    <p class='phone'><cite>Erik:</cite> 2nd F2F meeting will be in
    Ghent in Belgium, on 9 and 10 of December<br />
    ... Observers will be allowed</p>

    <p class='phone'>Quick straw poll: 6 people will make it +
    possibly more</p>

    <p class='phone'><cite>scribe:</cite> Silvia and Guillaume will
    participate remotely</p><a name="action02" id="action02"></a>

    <p class='irc'>&lt;<cite>scribe</cite>&gt;
    <strong>ACTION:</strong> setup Zakim for the 2nd face to face
    meeting [recorded in <a href=
    "http://www.w3.org/2008/10/21-mediafrag-minutes.html#action02">http://www.w3.org/2008/10/21-mediafrag-minutes.html#action02</a>]</p>

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

    <p class='phone'>Possible groups we will interact with: SYMM,
    SVG, HTML5, TAG, HTTP</p>

    <p class='phone'><cite>Raphael:</cite> we need to agree on a
    roadmap<br />
    ... for creating editor's draft to have quickly feedback<br />
    ... I would suggest to have a document that contains the Use
    Cases + descriptions + sketch of the solutions we have
    foreseen<br />
    ... 2-way handshake, 4-way handshake, etc.</p>

    <p class='phone'><cite>Silvia:</cite> I can create a new wiki
    page cleaning up the existing UCs</p>

    <h3 id="item04">URI Fragment / URI Query</h3>

    <p class='phone'><cite>Guillaume:</cite> go back to the
    commutative property of a non functional syntax for expressing
    the syntax of the fragment</p>

    <p class='phone'><cite>Jack:</cite> first investigate the '#'
    scenario<br />
    ... wait for the feedback of the other groups<br />
    ... see if it works before considering the '?'</p>

    <p class='phone'>Everybody nodds and agrees with Jack</p>

    <p class='phone'><cite>Silvia:</cite> in a way, we have defined
    how to do this communication server side with a '#'</p>

    <h3 id="item05">Fragment Name and Description</h3>

    <p class='phone'><cite>Problems:</cite> gives a name to a
    fragment, how to communicate this to the server?</p>

    <p class='phone'><cite>Silvia:</cite> URI#;name=test ... a
    Range request: fragment test<br />
    ... and then a 4-way handshake</p>

    <p class='phone'><cite>Jack:</cite> do we envision that the UA
    will pass to the server what is after the hash through http
    headers?</p>

    <p class='phone'><cite>Silvia:</cite> be carreful of the number
    of new http headers we will create<br />
    ... same http header but new headers</p>

    <p class='irc'>&lt;<cite>nessy</cite>&gt; <a href=
    "http://www.iana.org/assignments/message-headers/perm-headers.html">
    http://www.iana.org/assignments/message-headers/perm-headers.html</a></p>

    <p class='phone'><cite>Raphael:</cite> we consider the names
    will be unique<br />
    ... if there are multiple occurences of a name within the same
    resource, then the UA might go to the first one</p>

    <p class='phone'><cite>Jack:</cite> are these names UTF-8
    encoded strings?<br />
    ... can we have Japanese characters into these names?<br />
    ... I want to do names ... and moreover, the syntax can cope
    with any names which are allowable in other media formats</p>

    <p class='irc'>&lt;<cite>nessy</cite>&gt; quicktime example:
    <a href=
    "http://peepcode.com/pages/quicktime-chapter-track">http://peepcode.com/pages/quicktime-chapter-track</a></p>

    <p class='irc'>&lt;<cite>nessy</cite>&gt; jumping directly to
    chapters inside a quicktime chapter track</p>

    <p class='phone'><cite>Jack:</cite> we might need some quoting
    characters for the names<br />
    ... if there is a quicktime addressing naming scheme, we need
    to learn about</p>

    <p class='phone'><cite>Silvia:</cite> will look for</p>

    <h3 id="item06">Status of a Media Fragment</h3>

    <p class='irc'>&lt;<cite>guillaume</cite>&gt; "frame label" or
    "named anchors" for Flash <a href=
    "http://noscope.com/journal/2004/04/named-anchors">http://noscope.com/journal/2004/04/named-anchors</a>
    looking for example</p>

    <p class='phone'><cite>Raphael:</cite> might be relevant if we
    want to explicitely create new resources</p>

    <p class='phone'><cite>Yves:</cite> explains the latest
    Internet Draft, with the HTTP Header Linking<br />
    ... can be used to point to the parent resource</p><a name=
    "action03" id="action03"></a>

    <p class='irc'>&lt;<cite>scribe</cite>&gt;
    <strong>ACTION:</strong> Yves to look at more deeply if it is
    possible to use the current HTTP header linking for a fragment
    to point to its parent resource [recorded in <a href=
    "http://www.w3.org/2008/10/21-mediafrag-minutes.html#action03">http://www.w3.org/2008/10/21-mediafrag-minutes.html#action03</a>]</p>

    <p class='irc'>&lt;<cite>trackbot</cite>&gt; Created ACTION-8 -
    Look at more deeply if it is possible to use the current HTTP
    header linking for a fragment to point to its parent resource
    [on Yves Lafon - due 2008-10-28].</p>

    <p class='irc'>&lt;<cite>nessy</cite>&gt; xpointer registry
    <a href=
    "http://www.w3.org/2005/04/xpointer-schemes/">http://www.w3.org/2005/04/xpointer-schemes/</a></p>

    <p class='phone'><cite>Jack:</cite> there is XPointer ... why
    is it still a WD since 2001?</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; Xpointer spec:
    <a href=
    "http://www.w3.org/TR/WD-xptr">http://www.w3.org/TR/WD-xptr</a></p>

    <p class='phone'><cite>Yves:</cite> I will ask Liam Quin what's
    going on</p>

    <p class='irc'>&lt;<cite>Yves</cite>&gt; <a href=
    "http://www.w3.org/TR/xptr-framework/">http://www.w3.org/TR/xptr-framework/</a></p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; XPointer rec
    that google cannot find: <a href=
    "http://www.w3.org/TR/2003/REC-xptr-framework-20030325/">http://www.w3.org/TR/2003/REC-xptr-framework-20030325/</a></p>

    <p class='phone'><cite>Silvia:</cite> is XPointer only valid
    for XML documents?</p>

    <p class='phone'><cite>Jack:</cite> yep, you're right</p>

    <p class='phone'><cite>Raphael:</cite> XML is a structured
    document, this is not our case, should not copy the syntax</p>

    <p class='phone'><cite>All:</cite> looking at <a href=
    "http://www.ietf.org/rfc/rfc5147.txt">http://www.ietf.org/rfc/rfc5147.txt</a></p>

    <p class='phone'><cite>Silvia:</cite> should be added to my
    current #&lt;something&gt; list<br />
    ... '#&lt;alpha&gt;' [HTML], '#mf(...)' [MPEG-21], '#line=' or
    '#char=' [RFC5147]</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; One of the
    rfc5147 authors had an article at Hypertext 2005 on the
    subject, see <a href=
    "http://dret.net/netdret/docs/wilde-ht2005-textfrag.pdf">http://dret.net/netdret/docs/wilde-ht2005-textfrag.pdf</a></p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; (refers to
    various people we know, too:-)</p>

    <h3 id="item07">Server, Cache and Proxies</h3>

    <p class='phone'>It is desirable that new and old proxies are
    able to cache fragments</p>

    <p class='phone'><cite>Yves:</cite> a proxy does not
    necessarily cache only resources<br />
    ... should not be a problem with the solution we have
    sketched</p>

    <h3 id="item08">Protocols</h3>

    <p class='phone'>RTSP has a scheme for temporal URI ... but not
    for spatial URI</p>

    <p class='phone'><cite>Silvia:</cite> we need to look at how
    they do that and potentially tell them to adopt our scheme</p>

    <p class='phone'><cite>Davy:</cite> shoutcast should work over
    http</p>

    <p class='phone'><cite>Guillaume:</cite> mms is huge</p>

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

    <h3 id="item09">Wrap-up</h3>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; Two papers on
    potential use cases for fragment (please don't share too widely
    just now, definitive versions later):</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; <a href=
    "http://homepages.cwi.nl/~jack/presentations/smilstate-for-rwab.pdf">
    http://homepages.cwi.nl/~jack/presentations/smilstate-for-rwab.pdf</a></p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; <a href=
    "http://homepages.cwi.nl/~jack/presentations/mm08sharing-for-mf.pdf">
    http://homepages.cwi.nl/~jack/presentations/mm08sharing-for-mf.pdf</a></p>

    <p class='phone'><cite>raphael:</cite> the following should be
    in a UC &amp; requirements doc</p>

    <p class='phone'>1. Addressing</p>

    <p class='phone'>3 dimensions: temporal, spatial, track</p>

    <p class='phone'><cite>scribe:</cite> another dimension: named
    fragments</p>

    <p class='phone'>2. UA -&gt; Server communication</p>

    <p class='phone'><cite>scribe:</cite> only for http<br />
    ... 2-way handshake and 4-way handshake</p>

    <p class='phone'><cite>jack:</cite> use cases should be
    described before this</p>

    <p class='phone'><cite>raphael:</cite> silvia will clean up the
    wiki, at next teleconf, we will see what we have and take a
    decision<br />
    ... description of the use cases could be used as examples for
    the addressing part</p>

    <p class='phone'><cite>jack:</cite> should existing
    technologies be present in the doc?</p>

    <p class='phone'><cite>raphael:</cite> that would be great, but
    we will not have the time before the second f2f<br />
    ... it is a todo<br />
    ... smil, svg view, mpeg-21, temporal uri, ...</p>

    <p class='phone'><cite>silvia:</cite> does SMIL have an
    addressing scheme? If not, it should not be addressed</p>

    <p class='phone'><cite>guillaume:</cite> point is what does the
    technologies already do</p>

    <p class='phone'><cite>jack:</cite> indeed, think
    functionality</p>

    <p class='phone'><cite>raphael:</cite> URI solutions: XPointer,
    RFC3986, Temporal URI, SVG view, MPEG-21 Part 17<br />
    ... non-URI solutions: SMIL, SVG, MPEG-7</p>

    <p class='phone'><cite>silvia:</cite> bottom-line is about
    fragment identification possibilities by comparing these
    technologies</p>

    <p class='phone'><cite>jack:</cite> also add TimedText and CMML
    to the non-URI solutions</p>

    <p class='phone'><cite>silvia:</cite> add HTML 5</p>

    <p class='phone'><cite>raphael:</cite> add RTSP to point 2
    (UA-&gt;Server communication)</p>

    <p class='irc'>&lt;<cite>jun</cite>&gt; PDF Open Parameters:
    <a href=
    "http://partners.adobe.com/public/developer/en/acrobat/PDFOpenParameters.pdf">
    http://partners.adobe.com/public/developer/en/acrobat/PDFOpenParameters.pdf</a></p>

    <p class='phone'><cite>raphael:</cite> what about MMS and all
    the P2P protocols (e.g., subcast, pplive, ...)</p>

    <p class='phone'><cite>silvia:</cite> find out if these specs
    support fragments</p>

    <p class='phone'><cite>erik:</cite> are these P2P protocols
    open?</p>

    <p class='phone'><cite>raphael:</cite> yes, I think so, they
    are mainly built by Chinese people</p>

    <p class='phone'><cite>davy:</cite> is MMS not depricated?</p>

    <p class='irc'>&lt;<cite>jackjansen</cite>&gt; WMP11 does play
    MMS: <a href=
    "http://www.tipandtrick.net/2008/solution-to-windows-media-player-11-wmp11-cannot-stream-and-play-mms-media-protocol-in-vista/">
    http://www.tipandtrick.net/2008/solution-to-windows-media-player-11-wmp11-cannot-stream-and-play-mms-media-protocol-in-vista/</a></p>

    <p class='phone'><cite>silvia:</cite> most protocols will have
    http or rtsp+udp as underlaying layer</p>

    <p class='phone'><cite>raphael:</cite> in other groups: the
    whole group is editor<br />
    ... is this the solution we want?</p>

    <p class='phone'><cite>silvia:</cite> we are a small group, so
    it would not be a big problem</p>

    <p class='phone'><cite>raphael:</cite> editor as group, then no
    explicit names are given</p>

    <p class='phone'><cite>jack:</cite> are editors the text
    writers or the contributers?</p>

    <p class='phone'><cite>yves:</cite> there is also an
    acknowledgements section</p>

    <p class='phone'><cite>raphael:</cite> I volunteer to write
    about point 2</p>

    <p class='phone'><cite>jack:</cite> related technologies: we
    should have a comparison based on point 1<br />
    ... I will prepare a first version of point 3, erik &amp; davy
    prepare a second version<br />
    ... is creating a movie which will be used as test case for the
    technologies</p>

    <p class='phone'><cite>guillaume:</cite> I also want to add
    some examples for existing technologies</p>

    <p class='phone'><cite>raphael:</cite> could we have some dummy
    implementations for point 2</p>

    <p class='phone'><cite>yves:</cite> I have a Java
    implementation of a web server</p>

    <p class='phone'><cite>raphael:</cite> is there any existing
    Java cropping software?</p>

    <p class='phone'><cite>silvia:</cite> there is one for mp3</p>

    <p class='phone'><cite>yves:</cite> we would also need
    customization of the browser code</p>

    <p class='phone'><cite>erik:</cite> all doc preparation on the
    wiki</p>

    <p class='phone'><cite>guillaume:</cite> introduce 4.
    Syntax</p>

    <p class='phone'><cite>raphael:</cite> adjourns the meeting</p>
  </div>

  <h2><a name="ActionSummary" id="ActionSummary">Summary of Action
  Items</a></h2><!-- Action Items -->
  <strong>[NEW]</strong> <strong>ACTION:</strong> setup Zakim for
  the 2nd face to face meeting [recorded in <a href=
  "http://www.w3.org/2008/10/21-mediafrag-minutes.html#action02">http://www.w3.org/2008/10/21-mediafrag-minutes.html#action02</a>]<br />

  <strong>[NEW]</strong> <strong>ACTION:</strong> Yves to look at
  more deeply if it is possible to use the current HTTP header
  linking for a fragment to point to its parent resource [recorded
  in <a href=
  "http://www.w3.org/2008/10/21-mediafrag-minutes.html#action03">http://www.w3.org/2008/10/21-mediafrag-minutes.html#action03</a>]<br />

  <strong>[NEW]</strong> <strong>ACTION:</strong> Yves to request a
  new time slot on the Zakim bridge [recorded in <a href=
  "http://www.w3.org/2008/10/21-mediafrag-minutes.html#action01">http://www.w3.org/2008/10/21-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.133 (<a href=
    "http://dev.w3.org/cvsweb/2002/scribe/">CVS log</a>)<br />
    $Date: 2008/10/26 10:50:37 $
  </address>

</body>
</html>