You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
853 lines
31 KiB
853 lines
31 KiB
<!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'> </p>
|
|
|
|
<p class='phone'> </p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> trackbot, start
|
|
telcon</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Date: 21 October
|
|
2008</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> Scribenick:
|
|
raphael</p>
|
|
|
|
<p class='irc'><<cite>scribe</cite>> Scribe: Erik</p>
|
|
|
|
<p class='irc'><<cite>scribe</cite>> 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 & 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'><<cite>Yves</cite>> <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 & 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'><<cite>guillaume</cite>> 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 & 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 & 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'><<cite>raphael</cite>> 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'><<cite>raphael</cite>> 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'><<cite>guillaume</cite>> Jack: Couldn't we
|
|
have a "must understand"?</p>
|
|
|
|
<p class='irc'><<cite>erik</cite>> 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'><<cite>jackjansen</cite>> <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'><<cite>nessy</cite>> <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 '&'
|
|
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&month=11&year=2008&hour=09&min=30&sec=0&p1=0">
|
|
http://www.timeanddate.com/worldclock/fixedtime.html?day=05&month=11&year=2008&hour=09&min=30&sec=0&p1=0</a></p>
|
|
|
|
<p class='irc'><<cite>nessy</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>erik</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>guillaume</cite>> +1</p><a name=
|
|
"action01" id="action01"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<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'><<cite>trackbot</cite>> 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'><<cite>scribe</cite>>
|
|
<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'><<cite>trackbot</cite>> 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'><<cite>nessy</cite>> <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'><<cite>nessy</cite>> quicktime example:
|
|
<a href=
|
|
"http://peepcode.com/pages/quicktime-chapter-track">http://peepcode.com/pages/quicktime-chapter-track</a></p>
|
|
|
|
<p class='irc'><<cite>nessy</cite>> 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'><<cite>guillaume</cite>> "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'><<cite>scribe</cite>>
|
|
<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'><<cite>trackbot</cite>> 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'><<cite>nessy</cite>> 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'><<cite>jackjansen</cite>> 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'><<cite>Yves</cite>> <a href=
|
|
"http://www.w3.org/TR/xptr-framework/">http://www.w3.org/TR/xptr-framework/</a></p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> 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 #<something> list<br />
|
|
... '#<alpha>' [HTML], '#mf(...)' [MPEG-21], '#line=' or
|
|
'#char=' [RFC5147]</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> 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'><<cite>jackjansen</cite>> (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'><<cite>davy</cite>> scribenick: davy</p>
|
|
|
|
<h3 id="item09">Wrap-up</h3>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> Two papers on
|
|
potential use cases for fragment (please don't share too widely
|
|
just now, definitive versions later):</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> <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'><<cite>jackjansen</cite>> <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 & 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 -> 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->Server communication)</p>
|
|
|
|
<p class='irc'><<cite>jun</cite>> 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'><<cite>jackjansen</cite>> 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 & 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 />
|
|
|
|
<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>
|