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.
1390 lines
50 KiB
1390 lines
50 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 -- 16 Apr
|
|
2009</title>
|
|
<link type="text/css" rel="STYLESHEET" href=
|
|
"http://www.w3.org/StyleSheets/base.css" />
|
|
<link type="text/css" rel="STYLESHEET" href=
|
|
"http://www.w3.org/StyleSheets/public.css" />
|
|
<link type="text/css" rel="STYLESHEET" href=
|
|
"http://www.w3.org/2004/02/minutes-style.css" />
|
|
<meta content="Media Fragments Working Group Teleconference"
|
|
name="Title" />
|
|
<meta content="text/html; charset=utf-8" http-equiv=
|
|
"Content-Type" />
|
|
</head>
|
|
|
|
<body>
|
|
<p><a href="http://www.w3.org/"><img src=
|
|
"http://www.w3.org/Icons/w3c_home" alt="W3C" border="0" height=
|
|
"48" width="72" /></a></p>
|
|
|
|
<h1>Media Fragments Working Group Teleconference</h1>
|
|
|
|
<h2>16 Apr 2009</h2>
|
|
|
|
<p><a href=
|
|
'http://www.w3.org/2008/WebVideo/Fragments/wiki/ThirdF2FAgenda'>Agenda</a></p>
|
|
|
|
<p>See also: <a href=
|
|
"http://www.w3.org/2009/04/16-mediafrag-irc">IRC log</a></p>
|
|
|
|
<h2><a name="attendees" id="attendees">Attendees</a></h2>
|
|
|
|
<div class="intro">
|
|
<dl>
|
|
<dt>Present</dt>
|
|
|
|
<dd>conrad, michael, jack, erik, davy,
|
|
frank_(canon_observer), raphael, dave_singer, silvia_(phone),
|
|
yves_(phone)</dd>
|
|
|
|
<dt>Regrets</dt>
|
|
|
|
<dt>Chair</dt>
|
|
|
|
<dd>Erik, Raphael</dd>
|
|
|
|
<dt>Scribe</dt>
|
|
|
|
<dd>raphael</dd>
|
|
</dl>
|
|
</div>
|
|
|
|
<h2>Contents</h2>
|
|
|
|
<ul>
|
|
<li>
|
|
<a href="#agenda">Topics</a>
|
|
|
|
<ol>
|
|
<li><a href="#item01">1. Administrative</a></li>
|
|
|
|
<li><a href="#item02">2. Yves/Silvia/Conrad: Specification
|
|
discussion</a></li>
|
|
|
|
<li><a href="#item03">discoverability</a></li>
|
|
|
|
<li><a href="#item04">Numbers of documents</a></li>
|
|
</ol>
|
|
</li>
|
|
|
|
<li><a href="#ActionSummary">Summary of Action Items</a></li>
|
|
</ul>
|
|
<hr />
|
|
|
|
<div class="meeting">
|
|
<p class='phone'> </p>
|
|
|
|
<p class='phone'> </p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Date: 16 April
|
|
2009</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> to fill you in:
|
|
we can physically call, but we may run into trouble with uni
|
|
burocracy here.</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> Will try
|
|
something else.</p>
|
|
|
|
<p class='phone'>Silvia, you can use the phone number and code
|
|
above</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> but you will be alone on
|
|
the phone</p>
|
|
|
|
<p class='phone'>we will phone through skype</p>
|
|
|
|
<p class='phone'>but get the mic and speaker from a laptop</p>
|
|
|
|
<p class='phone'>interim solution till lunch, when we hope to
|
|
talk to MIT guys that can call us</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> yves: is the
|
|
thing that needs to be done at MIT a one-time action? i.e. if
|
|
they do the magic later today, will we be able</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> ... to use the
|
|
speakerphone tomorrow morning?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> jack; I will ask what
|
|
is possible</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> we R in!</p>
|
|
|
|
<p class='irc'><<cite>scribe</cite>> Scribe: raphael</p>
|
|
|
|
<p class='irc'><<cite>scribe</cite>> Scribenick:
|
|
raphael</p>
|
|
|
|
<h3 id="item01">1. Administrative</h3>
|
|
|
|
<p class='phone'>Agenda is at: <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/wiki/ThirdF2FAgenda">
|
|
http://www.w3.org/2008/WebVideo/Fragments/wiki/ThirdF2FAgenda</a></p>
|
|
|
|
<p class='phone'>Chairs would like to ammend the agenda, and
|
|
start with a proposal to publish our FPWD</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> needs the group
|
|
approval</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> I think I have corrected
|
|
all the markup errors</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> +1</p>
|
|
|
|
<p class='phone'><cite>PROPOSAL:</cite> publish the document at
|
|
<a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/">
|
|
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/</a>
|
|
as a first public working draft</p>
|
|
|
|
<p class='phone'>Any objections ?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> no objections -
|
|
publication approved</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> no
|
|
objections</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> no objections</p>
|
|
|
|
<p class='irc'><<cite>erik</cite>> no objections</p>
|
|
|
|
<p class='phone'>no objections</p>
|
|
|
|
<p class='irc'><<cite>davy</cite>> no objections</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> no
|
|
objections</p>
|
|
|
|
<p class='phone'>Please, dave, so you have any objections to
|
|
publish <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/">
|
|
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/</a>
|
|
as a FPWD?</p>
|
|
|
|
<p class='irc'><<cite>dsinger</cite>> no, we can publish
|
|
and continue to revise, that's fine</p>
|
|
|
|
<p class='irc'><<cite>dsinger</cite>> I mean, no
|
|
objections</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> same :)</p>
|
|
|
|
<p class='phone'><strong class='resolution'>RESOLUTION: The
|
|
Media Fragments agree to publish its FPWD</strong></p>
|
|
|
|
<h3 id="item02">2. Yves/Silvia/Conrad: Specification
|
|
discussion</h3>
|
|
|
|
<p class='phone'>* discuss the story of the single-step vs
|
|
dual-step partial GET (aka 2-ways, 4-ways handshake);</p>
|
|
|
|
<p class='phone'>o discuss the Silvia's proposal: new headers
|
|
Accept-TimeURI, Accept-SpaceURI, Accept-TrackURI and
|
|
Accept-NameURI;</p>
|
|
|
|
<p class='phone'>o discuss Yves's proposal: a GET of the media
|
|
header (so a few bytes, depending on how much is enough), and
|
|
the server answers with that + one or more Link: headers
|
|
linking to different mappings (time to bytes is an example) or
|
|
at least a resolver URI, linking to the sub-resource, to parent
|
|
etc...</p>
|
|
|
|
<p class='phone'>o discuss the pro/cons of each solution</p>
|
|
|
|
<p class='phone'>* check with the evolving link header
|
|
draft;</p>
|
|
|
|
<p class='phone'>* Yves: present the clarifications of
|
|
HTTPBis.</p>
|
|
|
|
<p class='irc'><<cite>dsinger</cite>> I have detailed
|
|
comments, I'll try to get them to the group over these two
|
|
days</p>
|
|
|
|
<p class='phone'>Yves, can you call to hear us ?</p>
|
|
|
|
<p class='phone'>we are on the phone</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> blog: <a href=
|
|
"http://blog.gingertech.net/2008/11/10/media-fragment-uri-addressing/">
|
|
http://blog.gingertech.net/2008/11/10/media-fragment-uri-addressing/</a></p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> read the last
|
|
comment - FYI</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> we need to clarify, in the
|
|
dual step partial GET, how the resolution between time ranges
|
|
and bytes work</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> the WD now explains how
|
|
it works</p>
|
|
|
|
<p class='phone'>Yves is reading <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/#dual-step">
|
|
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/#dual-step</a></p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> there is something wrong in
|
|
the first reply, you have a Content-Range but a 200 OK
|
|
response<br />
|
|
... if there is a Content-Range header, it should be a 206
|
|
response</p>
|
|
|
|
<p class='phone'>Michael, I think a 100 response means the
|
|
server sends something, and then something else but no
|
|
interaction from the UA in the middle</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> while in our case the UA
|
|
remakes its request</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> Michael: I
|
|
agree with silvia re caching header but not caching the entire
|
|
message for scalability reasons</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> first concern should be on
|
|
user experience rather than caches/proxies efficiency .... they
|
|
would anyway tune the right way the softwares</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> not sure,
|
|
raphael re 100 response is totally out of question</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> Yves? what's
|
|
your opinion on this?</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> for spatial fragments,
|
|
there is no way we can cache things anyway</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> I'm not sure we should
|
|
forbid transcoding<br />
|
|
... I would ask for more people</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> your problem seems to be
|
|
that there is 2 requests<br />
|
|
... TBL had the same feeling in Cannes<br />
|
|
... but the first request has no real data, so no delay</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> correction: but the
|
|
first request retreives real data, so it is not unnecessary</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> I would approach some TAG
|
|
members informally</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> so having two HTTP
|
|
request/response cycles does not introduce noticeable overhead
|
|
in retrieving large amounts of data</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> Yves:
|
|
headers+keyframes are not fake data</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> they are, as they are
|
|
not part of the resource representation</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> Yves, i respectfully
|
|
disagree, they are a necessary part of the segment
|
|
representation</p><a name="action01" id="action01"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> Yves to ask the TAG whether
|
|
transcoding should be forbidden or not when we send a fragment
|
|
of a resource [recorded in <a href=
|
|
"http://www.w3.org/2009/04/16-mediafrag-minutes.html#action01">http://www.w3.org/2009/04/16-mediafrag-minutes.html#action01</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ACTION-62
|
|
- Ask the TAG whether transcoding should be forbidden or not
|
|
when we send a fragment of a resource [on Yves Lafon - due
|
|
2009-04-23].</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> of the segment, yes,
|
|
but not the whole resource, which is addressed by the first get
|
|
:)</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> plus there may be a
|
|
mismatch of content between the first and second request</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> the current WD does not say
|
|
which anwsers has headers data and which ones has just
|
|
headers</p>
|
|
|
|
<p class='phone'><cite>Conrad:</cite> let me explain how things
|
|
will work<br />
|
|
... I tend to see that the dual step is just a fallback of the
|
|
single step</p>
|
|
|
|
<p class='phone'>Conrad's schema:</p>
|
|
|
|
<p class='phone'><cite>Conrad:</cite> user request URL =
|
|
<a href=
|
|
"http://www.example.com/video.ogg?t=10">http://www.example.com/video.ogg?t=10</a>,20</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> We lost our
|
|
network.</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> And our
|
|
phone.</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> Time for
|
|
coffee.</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> in temporal URI for
|
|
annodex, we only used ? for remote retrievals - # was done
|
|
locally only in the client</p>
|
|
|
|
<p class='phone'>trackbot, start teleco</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Sorry, raphael, I
|
|
don't understand 'trackbot, start teleco'. Please refer to
|
|
<a href=
|
|
"http://www.w3.org/2005/06/tracker/irc">http://www.w3.org/2005/06/tracker/irc</a>
|
|
for help</p>
|
|
|
|
<p class='phone'>trackbot, start telecon</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Meeting: Media
|
|
Fragments Working Group Teleconference</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Date: 16 April
|
|
2009</p>
|
|
|
|
<p class='phone'>Yves with ? you have no problem, you just
|
|
return the whole fragment with header as a response to the GET,
|
|
no need to to anything extra</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> as ...?t=1,2 is different
|
|
form ?t=2,3 and won't be cached as the same resource by caches
|
|
anyway</p>
|
|
|
|
<p class='phone'><cite>Conrad:</cite> back to the explanation,
|
|
I explain how temporalURI works</p>
|
|
|
|
<p class='irc'><<cite>philipj</cite>> hi all</p>
|
|
|
|
<p class='irc'><<cite>philipj</cite>> I browsed through
|
|
<a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/wiki/ThirdF2FAgenda">
|
|
http://www.w3.org/2008/WebVideo/Fragments/wiki/ThirdF2FAgenda</a>
|
|
but couldn't figure out which parts were on teleconf</p>
|
|
|
|
<p class='irc'><<cite>philipj</cite>> would be nice if
|
|
the next F2F were in Stockholm, since I live not too far from
|
|
there :)</p>
|
|
|
|
<p class='phone'>this is the agenda for the 2 days, we are now
|
|
on the first topic: Specification discussion</p>
|
|
|
|
<p class='phone'>Conrad agree with Yves's point</p>
|
|
|
|
<p class='phone'>Re: ? vs #</p>
|
|
|
|
<p class='phone'>Conrad will continue his explanation of
|
|
TemporalURI</p>
|
|
|
|
<p class='phone'><cite>Conrad:</cite> URL = <a href=
|
|
"http://www.example.com/video.ogv?t=10">http://www.example.com/video.ogv?t=10</a>,20<br />
|
|
|
|
... Client do a GET URL<br />
|
|
... with a new header: Accept-Range-Refer: bytes<br />
|
|
... Server: it udnerstands the range referal<br />
|
|
... will answer a 200 OK<br />
|
|
... with new headers: Range-Refer: this, 0-1000</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> <a href=
|
|
"http://www.example.com/video.ogv?t=10">http://www.example.com/video.ogv?t=10</a>,20
|
|
is a plain URI, unrelated to <a href=
|
|
"http://www.example.com/video.ogv.">http://www.example.com/video.ogv.</a>
|
|
Why not serving the content directly?</p>
|
|
|
|
<p class='phone'>good question :-)</p>
|
|
|
|
<p class='phone'><cite>Conrad:</cite> ... Range-Refer: URL2,
|
|
a-b<br />
|
|
... Vary: Range-Refer and the body</p>
|
|
|
|
<p class='phone'><cite>Client:</cite> will make another GET
|
|
URL-2 request with the range a-b</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> in the case the server does
|
|
not understand the ?t=10,20 ... it will answer a 404</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> will answer with a
|
|
404... that depends on the server configuration</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> while in the case the
|
|
server does not understand the #t=10,20 the way we want, it
|
|
will send the whole resource, better for the UA</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> in some cases the ?
|
|
will be ignored and you will save in a cache 100+ times the
|
|
full content (attached to different URIs)</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> this is a URI the server
|
|
does not know about ... how can it be different from a 404
|
|
?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> raphael, try to access
|
|
<a href="http://www.w3.org/">http://www.w3.org/</a> and
|
|
<a href="http://www.w3.org/?foo=bar">http://www.w3.org/?foo=bar</a></p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> that example work with
|
|
lots of other servers ;)</p>
|
|
|
|
<p class='phone'>well done :-)</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> so accessing <a href=
|
|
"http://media.exampe.com/bigvideo.mp4">http://media.exampe.com/bigvideo.mp4</a>
|
|
<a href=
|
|
"http://media.exampe.com/bigvideo.mp4?t=1">http://media.exampe.com/bigvideo.mp4?t=1</a>,2</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> will cache twice the
|
|
big content</p>
|
|
|
|
<p class='irc'><<cite>philipj</cite>> unrecognized query
|
|
strings will almost certainly be ignored by most servers, not
|
|
return 404</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> all because of a quite
|
|
common server configuration issue</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> (as the right thing
|
|
would be to return a 404)</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> ok. So people
|
|
shouldn't issue ? temporal uris to non-capable servers.</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> jack, yes, basically
|
|
you need to know in advance</p>
|
|
|
|
<p class='irc'><<cite>philipj</cite>> sounds rather
|
|
unreliable</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> yep</p>
|
|
|
|
<p class='irc'><<cite>philipj</cite>> btw, is it worth
|
|
saying things on IRC or do I need to join by phone? I happen to
|
|
not have a phone nearby.</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> I still think that if
|
|
you have <a href=
|
|
"http://media.example.com/media?t=1">http://media.example.com/media?t=1</a>,10
|
|
should return the fragment with the header as a complete
|
|
resource</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> might also want
|
|
to take <a href=
|
|
"http://www.w3.org/2001/tag/doc/whenToUseGet.html#safe">http://www.w3.org/2001/tag/doc/whenToUseGet.html#safe</a>
|
|
into consideration ...</p>
|
|
|
|
<p class='irc'><<cite>philipj</cite>> Yves, haha, ok
|
|
then</p>
|
|
|
|
<p class='phone'>yep, this is what Conrad said too !</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> fragment + header meaning a
|
|
complete resource</p>
|
|
|
|
<p class='phone'><cite>Conrad:</cite> we will just ONE round
|
|
trip, and a 200 OK in the case of a capable server
|
|
understanding temporalURI<br />
|
|
... what is the fallback plan?</p>
|
|
|
|
<p class='irc'><<cite>philipj</cite>> how can one detect
|
|
if the server does not understand temporalURI?</p>
|
|
|
|
<p class='irc'><<cite>philipj</cite>> sorry, I will be
|
|
afk for lunch</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> wondering why
|
|
the server shouldn't just send a 501 <a href=
|
|
"http://tools.ietf.org/html/rfc2616#section-10.5.2">http://tools.ietf.org/html/rfc2616#section-10.5.2</a></p>
|
|
|
|
<p class='phone'>Conrad answer: in temporal URI, the client
|
|
uses another header: Accept-TimeURI</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> mhausenblas, in which
|
|
case?</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> what philipj
|
|
was asking and we are discussing here, now (server does not
|
|
understand temporalURI?)</p>
|
|
|
|
<p class='phone'><cite>scribe:</cite> further: the header in
|
|
the ogg file returned will contain a In-point=10, so the client
|
|
knows he didn't get the full resource, but this is media format
|
|
dependant<br />
|
|
... it will work for ogg, perhaps for mp4, but certainly not
|
|
for avi for example</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> or, how are
|
|
odds that HTTPbis will introduce a new code for that case
|
|
...</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> Yves, yes I
|
|
guess you are right, so just for the record, 501 is NO option,
|
|
right?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> (I was wondering if
|
|
you meant "if the server doesn't know how to handle it, it
|
|
should reply with a 501', which is againt the 'ignore what you
|
|
don't understand' paradigm)</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> so yes 501 is not an
|
|
option</p>
|
|
|
|
<p class='phone'><cite>Raphael:</cite> let's kick out the ? for
|
|
now, and work on the #</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> s/which is
|
|
against/which is against</p>
|
|
|
|
<p class='phone'><cite>Jack:</cite> our premises are that the
|
|
client are easy to modify, while your asumption is that you
|
|
think we should adop servers</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> +1 to raphael's
|
|
proposal to focus on the #</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> if the # implies
|
|
client sending a range request, then the server would do the
|
|
work</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> raphael: is
|
|
drawing a table</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> and the client will do
|
|
the work as a fallback</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> the intention
|
|
is to capture/structure the current state</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> Scribenick:
|
|
mhausenblas</p>
|
|
|
|
<p class='phone'><cite>raphael:</cite> two cases at the
|
|
table<br />
|
|
... either the UA makes a request using a unit like sec which
|
|
is transformed into range request<br />
|
|
... and the server knows how to handle the mapping</p>
|
|
|
|
<p class='phone'>Conrad agrees so far</p>
|
|
|
|
<p class='phone'><cite>raphael:</cite> the second case is where
|
|
we need a resolver</p>
|
|
|
|
<p class='phone'>Conrad again on the board</p>
|
|
|
|
<p class='phone'><cite>Conrad:</cite> client - GET URL,
|
|
Aceept-TimeURI, Media-Fragment: t=10,20<br />
|
|
... Server: 206 partial content (with body, H' + K + D2)</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> For the people
|
|
not in the room: the original media is H + D1 + D2 + D3</p>
|
|
|
|
<p class='phone'>and Server: Content-Range: in sec and bytes
|
|
(?)</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> ... D1 is
|
|
seconds 0-10, D2 10-20, D3 20-30.</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> ... H' is
|
|
modified header, K is synthetic keyframes etc. to be able to
|
|
interpret D2 correct.</p>
|
|
|
|
<p class='phone'><cite>Conrad:</cite> let's assume the URI is
|
|
.../video.ogg#t=smpte-25:00'10.23.25,<br />
|
|
... hence we need to specify the unit in the Range</p>
|
|
|
|
<p class='phone'><cite>raphael:</cite> if we specify the unit
|
|
in the Range, we can agree on that?</p>
|
|
|
|
<p class='phone'><cite>jackjansen:</cite> I ran into the same
|
|
issue when implementing it</p>
|
|
|
|
<p class='phone'>Yves, we are back</p>
|
|
|
|
<p class='phone'><cite>raphael:</cite> sums up last 5min</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> a new header won't
|
|
trigger partial responses</p>
|
|
|
|
<p class='phone'><cite>raphael:</cite> Conrad suggests to
|
|
introduce a new header and let the server do the magic</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> the right way would be
|
|
in this case to do conneg and point to a CL and a Vary, but in
|
|
that case we mandate multiple URIs, and defeat caches again
|
|
;)</p>
|
|
|
|
<p class='phone'><cite>Conrad:</cite> this was my first issue
|
|
with Range:<br />
|
|
... now second</p>
|
|
|
|
<p class='phone'>(scribe notes that we have not yet fully
|
|
resolved this issue)</p>
|
|
|
|
<p class='phone'>Yves, in *which* case - new header?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> if a new
|
|
Media-Fragment: header is introduced in place of Range</p>
|
|
|
|
<p class='phone'>ok, thanks for the clarification</p>
|
|
|
|
<p class='phone'>Conrad drawing UA - Proxy - Original
|
|
Server</p>
|
|
|
|
<p class='phone'><cite>Michael:</cite> note what 206 (<a href=
|
|
"http://tools.ietf.org/html/rfc2616#section-10.2.7)">http://tools.ietf.org/html/rfc2616#section-10.2.7)</a>
|
|
says about caching ...</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> michael, see also
|
|
<a href=
|
|
"http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-06">http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-06</a></p>
|
|
|
|
<p class='phone'>ta, Yves, was hoping that you come up with a
|
|
recent state ;)</p>
|
|
|
|
<p class='phone'>is there a big difference?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> no small
|
|
clarifications only</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> in rfc2616, the text
|
|
was open to new units, but without any way of doing it, in
|
|
httpbis it has been clarified</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> Yves: summary, we
|
|
understand the concern of Conrad: single step partial GET, with
|
|
a 206 response works, but it is not cachable</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> ... which we know,
|
|
written in 7.3 !</p>
|
|
|
|
<p class='phone'><cite>Michael:</cite> are we seeking a
|
|
trade-of between cachability and round-trip?</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> in current web
|
|
proxies not cachable</p>
|
|
|
|
<p class='phone'><cite>jackjansen:</cite> yes</p>
|
|
|
|
<p class='phone'><cite>Conrad:</cite> no</p>
|
|
|
|
<p class='phone'><cite>jackjansen:</cite> let' ignore the
|
|
No-Cache for now, different issue</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> things we can add is a
|
|
header in the reply indicating where D2 is and its relationship
|
|
to bytes in the original file</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I agree with the
|
|
addition of such a header</p>
|
|
|
|
<p class='phone'><cite>jackjansen:</cite> we should optimise
|
|
for the case where a URI is embedded in an Web page</p>
|
|
|
|
<p class='phone'><cite>silvia:</cite> for example in youtube
|
|
case, each time you click on a time-offset it's a different
|
|
URI</p>
|
|
|
|
<p class='phone'><cite>jackjansen:</cite> do I understand
|
|
correctly: every time I click on it I get a new URI?</p>
|
|
|
|
<p class='phone'><cite>silvia:</cite> yes</p>
|
|
|
|
<p class='phone'><cite>raphael:</cite> let's move on<br />
|
|
... we seem to agree on the one-step process but the cachable
|
|
part</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> in the YouTube case
|
|
there is a special server and a proprietary client - we cannot
|
|
really tell what is going on; but when you click on an offset,
|
|
a new connection is opened and new buffering is started</p>
|
|
|
|
<p class='phone'><cite>jackjansen:</cite> a super-clever proxy
|
|
would cache the entire bits and handle the parts
|
|
accordingly</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> and a not so clever
|
|
proxy could return the same content when the same second range
|
|
is requested</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> yes Yves</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> 'second' or 'other
|
|
unit then bytes'</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> Conrad would like
|
|
to move on the 4-ways handshake</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> but adding a mapping
|
|
header in the reply (if possible would be a good thing, and
|
|
only 'informative', so nothing mandatory to implement on the
|
|
receiving end</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> gui walks in</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I agree with
|
|
Yves</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> and that would help a
|
|
lot Silvia and Conrad's use case</p>
|
|
|
|
<p class='phone'>Guilleaume has arrived</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> +1 for Yves</p>
|
|
|
|
<p class='phone'>+1 as well from me</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> Conrad: I don't
|
|
think doing 200 response or 206 response should be our goal</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> ... my solution
|
|
will add new headers on the client side but would be pretty
|
|
similar</p>
|
|
|
|
<p class='phone'>Conrad now explains now his solution with #
|
|
and no Range</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> I will take a
|
|
picture of Conrad complet's proposal</p>
|
|
|
|
<p class='phone'><cite>Conrad:</cite> GET URL,
|
|
Accept-Range-Refer: bytes, Media-Fragment:t=10,20</p>
|
|
|
|
<p class='phone'><cite>Server:</cite> 200 OK, body
|
|
Hi+K+D2<br />
|
|
... and additionally a header in the response ...
|
|
Content-Media-Fragment:t=10,20</p>
|
|
|
|
<p class='phone'>(it's raining)</p>
|
|
|
|
<p class='phone'><cite>Conrad:</cite> Range-Refer: this,
|
|
0-1000</p>
|
|
|
|
<p class='phone'>note that 'this' is meant verbatim</p>
|
|
|
|
<p class='phone'><cite>Conrad:</cite> continuing Range-Refer:
|
|
URL2, Varu: Range-Refer, body</p>
|
|
|
|
<p class='phone'><cite>jackjansen:</cite> let's not use 'this'
|
|
but just blank (?)</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> ping</p>
|
|
|
|
<p class='phone'>(we seem to agree to disagree)</p>
|
|
|
|
<p class='phone'><cite>raphael:</cite> see no big difference
|
|
between Conrad's proposal and what is in the current draft</p>
|
|
|
|
<p class='phone'>right</p>
|
|
|
|
<p class='phone'>Yves is leaving</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> PIctures are in
|
|
<a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/meetings/2009-04-16-f2f_barcelona/">
|
|
http://www.w3.org/2008/WebVideo/Fragments/meetings/2009-04-16-f2f_barcelona/</a></p>
|
|
|
|
<p class='phone'><cite>jackjansen:</cite> we should structure
|
|
the document in the fall-back flow<br />
|
|
... much easier to grock, then</p>
|
|
|
|
<p class='phone'><cite>Michael:</cite> +1</p>
|
|
|
|
<p class='phone'><cite>Silvia:</cite> can we modify the current
|
|
draft and enhance it with Conrad's proposal?</p>
|
|
|
|
<p class='phone'><cite>raphael:</cite> still need to understand
|
|
better</p>
|
|
|
|
<p class='irc'><<cite>philipj</cite>> is the proposal to
|
|
allow either or both of these methods?</p>
|
|
|
|
<p class='irc'><<cite>philipj</cite>> conrad's single and
|
|
dual step GET</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> IIUC the one-step
|
|
GET is preferrable, but it doesn't work with existing Web proxy
|
|
caching infrastructure other than by keeping multiple copies;
|
|
the two-step GET is for making media fragment URIs work with
|
|
existing caching Web proxies</p>
|
|
|
|
<p class='phone'><cite>raphael:</cite> re philipj's question,
|
|
its a fallback-stack</p>
|
|
|
|
<p class='irc'><<cite>philipj</cite>> I see</p>
|
|
|
|
<p class='phone'><cite>raphael:</cite> in most of the cases,
|
|
URL and URL2 are identical</p>
|
|
|
|
<p class='phone'>(scribe notes also that there are two or more
|
|
servers involved)</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> where does a and b
|
|
come from? are they 0 - 1000 ?</p>
|
|
|
|
<p class='phone'><cite>raphael:</cite> before lunch two
|
|
questions<br />
|
|
... (1) for me the UA does not know that it has to do another
|
|
request</p>
|
|
|
|
<p class='phone'>and these will be discussed/ansewered after
|
|
lunch</p>
|
|
|
|
<p class='phone'><cite>jackjansen:</cite> is the more general
|
|
approach of Conrad worth it re the introduced complexity which
|
|
is apparently much higher</p>
|
|
|
|
<p class='phone'>+1</p><a name="action02" id="action02"></a>
|
|
|
|
<p class='irc'><<cite>scribe</cite>>
|
|
<strong>ACTION:</strong> Conrad to update the Wiki with his
|
|
more general approach with precisely the same exmples [recorded
|
|
in <a href=
|
|
"http://www.w3.org/2009/04/16-mediafrag-minutes.html#action02">http://www.w3.org/2009/04/16-mediafrag-minutes.html#action02</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ACTION-63
|
|
- Update the Wiki with his more general approach with precisely
|
|
the same exmples [on Conrad Parker - due 2009-04-23].</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I still do not
|
|
understand the different</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> yes, please :)</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> time for lunch.
|
|
Silvia: will you still be here later?</p>
|
|
|
|
<p class='phone'>sorry, silvia you will have to wait a bit -
|
|
Conrad suggests to read his blog ;)</p>
|
|
|
|
<p class='phone'>we will be back in roughly an hour</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> ok, I may not be
|
|
back</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I'm rather tired
|
|
tonight and the phone is really exhausting</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> but I will linger
|
|
here</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I read the blog,
|
|
which I found just as confusing :)</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> trackbot, start
|
|
telcon</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Meeting: Media
|
|
Fragments Working Group Teleconference</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Date: 16 April
|
|
2009</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>>
|
|
yeahhhhhhhhhhhhhhhh</p>
|
|
|
|
<p class='phone'><cite>raphael:</cite> Yves please update us on
|
|
HTTP Link: header</p>
|
|
|
|
<p class='irc'><<cite>jackjansen</cite>> raphael, are you
|
|
reffering to <a href=
|
|
"http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-06">http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-06</a>
|
|
?</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> yes</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> "If a range unit is
|
|
not understood in a request, a server MUST ignore</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> the whole Range
|
|
header"</p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> url for link header
|
|
draft?</p>
|
|
|
|
<p class='phone'><cite>Michael:</cite> see <a href=
|
|
"http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0189.html">
|
|
http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0189.html</a>
|
|
for updates on HTTP Link:</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> <a href=
|
|
"http://tools.ietf.org/html/draft-nottingham-http-link-header-04">
|
|
http://tools.ietf.org/html/draft-nottingham-http-link-header-04</a></p>
|
|
|
|
<p class='phone'><cite>jackjansen:</cite> if only partially
|
|
available? say file is 100bytes, and I request 50 - 150, it
|
|
will be cut of at 100?</p>
|
|
|
|
<p class='phone'><cite>Yves:</cite> yes</p>
|
|
|
|
<p class='phone'><cite>jackjansen:</cite> all our replies
|
|
should hence also incl. the time range, not only the bytes</p>
|
|
|
|
<p class='phone'><cite>raphael:</cite> we will also have to be
|
|
more precisely in the edge cases handling and their
|
|
explanation</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> if you always get 200
|
|
you won't get fragments :)</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> <a href=
|
|
"http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-06#section-3.2">
|
|
http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-06#section-3.2</a></p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> is actually
|
|
unit-agnostic</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> yep, I phrased that
|
|
wrongly</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> "none of the</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> ranges-specifier
|
|
values in this field overlap the current extent of</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> the selected
|
|
resource"</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> In Conrad's
|
|
proposal, in the case of the dual-step partial GET, the second
|
|
request is still a normal Range request, so will get the normal
|
|
206 (or 416) response code</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> ... only the first
|
|
request will be answered by a 200 OK response, since it
|
|
contains just the header + key frames data in the body</p>
|
|
|
|
<p class='phone'><cite>jackjansen:</cite> so, if the query
|
|
would be empty in any of the dimension, the result would be a
|
|
416</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/meetings/2009-04-16-f2f_barcelona/">
|
|
http://www.w3.org/2008/WebVideo/Fragments/meetings/2009-04-16-f2f_barcelona/</a></p>
|
|
|
|
<p class='irc'><<cite>conrad</cite>> <a href=
|
|
"http://blog.kfish.org/2009/04/proposal-for-generalizing-byte-range.html">
|
|
http://blog.kfish.org/2009/04/proposal-for-generalizing-byte-range.html</a></p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> ohh</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> that's bad</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> two axis to identify a
|
|
resource :)</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> URI request +
|
|
media-fragment header</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> why do you need to
|
|
send H1+K in the first request as you do a request to URL2
|
|
where you can send the whole thing?</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> because the answer
|
|
of the second GET will be cached ?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> what is the
|
|
relationship between URL and URL2?</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> URL = URL 2</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> ... in most of the
|
|
cases</p>
|
|
|
|
<p class='phone'>90% yes ;)</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> ?????</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> Jack: is your
|
|
URL/URL2 re-inventing the http-redirect?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> I don't get why we
|
|
need this complexity. at worst we need to locate a resolver and
|
|
get the API to call it</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> I *think* the main
|
|
purpose is to have the cacheability feature on the code
|
|
data</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> ... but I think we
|
|
have it with the current dual-step partial GET</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> Conrad: we need to
|
|
do a bytes redirection for the second request</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> Raphael: in the
|
|
spec, we have currently: X-Range-Redirect (new header)</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> ... Yves, how will
|
|
you tell the user agent needs to issue another request to get
|
|
the core of the video data ? do we need this new header ?</p>
|
|
|
|
<p class='phone'><cite>Michael:</cite> I would be very careful
|
|
introducing complexity if the benefit is not totally clear and
|
|
'fool-proof'; lowers implementation barriers if we keep it
|
|
simple</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> Jack: well, it is
|
|
good in theory to call for a resolver (do the mapping between
|
|
bytes and seconds) ... but in practice, this resolver will need
|
|
to construct K (the key frames)</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> ... thus access the
|
|
media, thus be on the server</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> Raphael: Yves, what
|
|
is not clear in the current draft (among others :-), is the
|
|
content of the body response of the first request in the dual
|
|
step GET</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> ... should we have
|
|
just the video data header (H') constructed on the server ?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> I think that the
|
|
clarification using letters is quite good and shoul make it to
|
|
the 2nd publication :)</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> ... should we add
|
|
also K (the key frames)</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> do you have the
|
|
picture with the H, K?</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> Yves, <a href=
|
|
"http://www.w3.org/2008/WebVideo/Fragments/meetings/2009-04-16-f2f_barcelona/ogv_video_decomposition.jpg">
|
|
http://www.w3.org/2008/WebVideo/Fragments/meetings/2009-04-16-f2f_barcelona/ogv_video_decomposition.jpg</a>
|
|
for the H, H', K, etc.</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> Yves: in the
|
|
current draft, we haven't specify what is in the BODY of each
|
|
response, right ?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> no, but we should</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> Conrad mentions
|
|
that in his solution: 1st response body contains the H' and K
|
|
(new information/bytes constructed on the server)</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> ... while the 2nd
|
|
response body contains only bytes coming from the original
|
|
file</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> in the single GET
|
|
solution the returned content should be H' K D2</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> ... and UA does the
|
|
concatenation to get a complete playable resource</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> YES</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> in the case of the
|
|
dual-step ?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> and we shold craft
|
|
that header to define where D2 is and its relation to the whole
|
|
resource, as bytes</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> how ?</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> like Range-Mapping:
|
|
bytes 1234-2345/58588; original=11234-12345/39849384</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> (or annodex might have
|
|
a better format for that already :) )</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> well, this is what
|
|
Conrad proposes with its Range-Refer ... re his blog post
|
|
:-)</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> no</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> he proposes a way to
|
|
redirect without redirecting</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> I propose a mapping
|
|
header for caches</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> he proposes to send
|
|
the headers in the body of the first request, and the real
|
|
video data in the body of the second request</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> on different URIs</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> I will bring your
|
|
position in the room</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> ... no no no,
|
|
assume now that URI = URI2</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> then it will confuse
|
|
caches :)</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> basically if URL=URL2
|
|
the cache will flush what it cached at each request</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> well, the first
|
|
response is not meant to be cached (just headers), the second
|
|
one is a clear extract in terms of bytes of the resource and
|
|
will be cached</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> the request is not
|
|
the same</p>
|
|
|
|
<p class='irc'><<cite>Yves</cite>> yeah, but a subsequent
|
|
request on the same thing will invalidate what has just been
|
|
cached</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> no, if this is not
|
|
the same request ?</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> the second request
|
|
is a normal Range request</p>
|
|
|
|
<p class='phone'><cite>jackjansen:</cite> let's use an example
|
|
video (from last F2F) and do practical experiments<br />
|
|
... and figure out how different formats (MPEG4, OGG) actually
|
|
behave</p>
|
|
|
|
<p class='phone'><cite>Michael:</cite> I second jackjansen
|
|
proposal</p>
|
|
|
|
<p class='phone'><cite>raphael:</cite> yes, let's do it and
|
|
document in the Wiki</p>
|
|
|
|
<p class='irc'><<cite>scribe</cite>> Scribenick:
|
|
guillaume</p>
|
|
|
|
<h3 id="item03">discoverability</h3>
|
|
|
|
<p class='phone'><cite>Previously:</cite> Describe Conrad
|
|
solution using the example (http implementation wiki page) to
|
|
be enhanced with Conrad proposal</p>
|
|
|
|
<p class='phone'><cite>Conrad:</cite> what happen when we come
|
|
across an URL like
|
|
video.ogv#t=smpte-25=00'10.23.25,...</p>
|
|
|
|
<p class='phone'>What would the code look like in the User
|
|
Agent (the "smart" user agent)</p>
|
|
|
|
<p class='phone'>It could be that the user agent split at the
|
|
#, then after the request, start parsing what' s after the #
|
|
(not good enough). It would have to check if it matches the
|
|
syntax first. Reply comes back.</p>
|
|
|
|
<p class='phone'>It' s the owner of the MIMIE type that
|
|
understands what' s happening beyond the # (because so far, #
|
|
"belongs / could be used" in any HTML document)</p>
|
|
|
|
<p class='phone'>The server knows the MIME type, hence, the way
|
|
to interpret the #etc...</p>
|
|
|
|
<p class='phone'>ACTION mhausenblas Michael to write into the
|
|
WD section 6.4, what the client should do with #everything
|
|
after the hash : "Client Side Media Fragment Resolution"</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Sorry, couldn't
|
|
find user - mhausenblas</p>
|
|
|
|
<p class='irc'><<cite>dsinger</cite>> servers don't get
|
|
the # part, it's supposed to be stripped by the UA, isn't
|
|
it?</p><a name="action03" id="action03"></a>
|
|
|
|
<p class='irc'><<cite>raphael</cite>>
|
|
<strong>ACTION:</strong> Michael to write into the WD section
|
|
6.4, what the client should do with #everything after the hash
|
|
: "Client Side Media Fragment Resolution" [recorded in <a href=
|
|
"http://www.w3.org/2009/04/16-mediafrag-minutes.html#action03">http://www.w3.org/2009/04/16-mediafrag-minutes.html#action03</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ACTION-64
|
|
- Write into the WD section 6.4, what the client should do with
|
|
#everything after the hash : "Client Side Media Fragment
|
|
Resolution" [on Michael Hausenblas - due 2009-04-23].</p>
|
|
|
|
<p class='phone'>Coffee break time!</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>>
|
|
coffeeeeeeeeeee</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> oh</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> I will probably be
|
|
asleep when you get back</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> looks like there is
|
|
progress :)</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> raphael: we
|
|
will do now the joint meeting with the Annotation WG</p>
|
|
|
|
<p class='phone'>Resuming</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> Zakim?</p>
|
|
|
|
<p class='phone'>Use cases + requirements could make 1 separate
|
|
document</p>
|
|
|
|
<p class='phone'>the specification of the syntax would be the
|
|
core document</p>
|
|
|
|
<p class='phone'>Yeah, the teleconf is working</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> Michael: we
|
|
should only go with the Syntax REC-Track</p>
|
|
|
|
<p class='phone'>We are going to have the joint meeting with
|
|
the Media Annotation WG</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> ... the Test
|
|
Cases (TC) and the Implementation Report (IR) should be a Note
|
|
only</p>
|
|
|
|
<h3 id="item04">Numbers of documents</h3>
|
|
|
|
<p class='phone'>1. Use cases & Reqs</p>
|
|
|
|
<p class='phone'>2. Synthax</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> raphael:
|
|
current UC and Req will be split into UCR and Syntax doc</p>
|
|
|
|
<p class='phone'>Action raphael Current UC and Req will be
|
|
split into UCR and Syntax doc</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Sorry, couldn't
|
|
find user - raphael</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> trackbot,
|
|
status</p>
|
|
|
|
<p class='phone'>Action Raphaël Current UC and Req will be
|
|
split into UCR and Syntax doc</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ACTION-65
|
|
- Current UC and Req will be split into UCR and Syntax doc [on
|
|
Raphaël Troncy - due 2009-04-23].</p>
|
|
|
|
<p class='phone'>3. Potentialy a 3rd document with Test
|
|
cases</p>
|
|
|
|
<p class='phone'>University people would like to make
|
|
publications out of the work we produce here at the MFWG.</p>
|
|
|
|
<p class='phone'>We would then add all our names to the joint
|
|
co-authored paper(s)</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> +1</p>
|
|
|
|
<p class='phone'>+1</p>
|
|
|
|
<p class='irc'><<cite>erik</cite>> +1</p>
|
|
|
|
<p class='irc'><<cite>silvia</cite>> +1 (papers are
|
|
always good )</p>
|
|
|
|
<p class='irc'><<cite>mhausenblas</cite>> ;)</p><a name=
|
|
"action04" id="action04"></a>
|
|
|
|
<p class='irc'><<cite>raphael</cite>>
|
|
<strong>ACTION:</strong> Jack to look at the organisation of
|
|
the 4th F2F meeting in Amsterdam on September 17-18 (just after
|
|
IBC) [recorded in <a href=
|
|
"http://www.w3.org/2009/04/16-mediafrag-minutes.html#action04">http://www.w3.org/2009/04/16-mediafrag-minutes.html#action04</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ACTION-66
|
|
- Look at the organisation of the 4th F2F meeting in Amsterdam
|
|
on September 17-18 (just after IBC) [on Jack Jansen - due
|
|
2009-04-23].</p><a name="action05" id="action05"></a>
|
|
|
|
<p class='irc'><<cite>raphael</cite>>
|
|
<strong>ACTION:</strong> Erik to sync with Jean Pierre to get
|
|
the edit units spec reference [recorded in <a href=
|
|
"http://www.w3.org/2009/04/16-mediafrag-minutes.html#action05">http://www.w3.org/2009/04/16-mediafrag-minutes.html#action05</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ACTION-67
|
|
- Sync with Jean Pierre to get the edit units spec reference
|
|
[on Erik Mannens - due 2009-04-23].</p><a name="action06" id=
|
|
"action06"></a>
|
|
|
|
<p class='irc'><<cite>raphael</cite>>
|
|
<strong>ACTION:</strong> Raphael to ask the Media Annotations
|
|
WG to review our document [recorded in <a href=
|
|
"http://www.w3.org/2009/04/16-mediafrag-minutes.html#action06">http://www.w3.org/2009/04/16-mediafrag-minutes.html#action06</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Sorry, couldn't
|
|
find user - Raphael</p>
|
|
|
|
<p class='irc'><<cite>raphael</cite>> trackbot,
|
|
status?</p><a name="action07" id="action07"></a>
|
|
|
|
<p class='irc'><<cite>raphael</cite>>
|
|
<strong>ACTION:</strong> Raphaël to ask the Media Annotations
|
|
WG to review our document [recorded in <a href=
|
|
"http://www.w3.org/2009/04/16-mediafrag-minutes.html#action07">http://www.w3.org/2009/04/16-mediafrag-minutes.html#action07</a>]</p>
|
|
|
|
<p class='irc'><<cite>trackbot</cite>> Created ACTION-68
|
|
- Ask the Media Annotations WG to review our document [on
|
|
Raphaël Troncy - due 2009-04-23].</p>
|
|
</div>
|
|
|
|
<h2><a name="ActionSummary" id="ActionSummary">Summary of Action
|
|
Items</a></h2><!-- Action Items -->
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> Conrad to update
|
|
the Wiki with his more general approach with precisely the same
|
|
exmples [recorded in <a href=
|
|
"http://www.w3.org/2009/04/16-mediafrag-minutes.html#action02">http://www.w3.org/2009/04/16-mediafrag-minutes.html#action02</a>]<br />
|
|
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> Erik to sync with
|
|
Jean Pierre to get the edit units spec reference [recorded in
|
|
<a href=
|
|
"http://www.w3.org/2009/04/16-mediafrag-minutes.html#action05">http://www.w3.org/2009/04/16-mediafrag-minutes.html#action05</a>]<br />
|
|
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> Jack to look at
|
|
the organisation of the 4th F2F meeting in Amsterdam on September
|
|
17-18 (just after IBC) [recorded in <a href=
|
|
"http://www.w3.org/2009/04/16-mediafrag-minutes.html#action04">http://www.w3.org/2009/04/16-mediafrag-minutes.html#action04</a>]<br />
|
|
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> Michael to write
|
|
into the WD section 6.4, what the client should do with
|
|
#everything after the hash : "Client Side Media Fragment
|
|
Resolution" [recorded in <a href=
|
|
"http://www.w3.org/2009/04/16-mediafrag-minutes.html#action03">http://www.w3.org/2009/04/16-mediafrag-minutes.html#action03</a>]<br />
|
|
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> Raphael to ask
|
|
the Media Annotations WG to review our document [recorded in
|
|
<a href=
|
|
"http://www.w3.org/2009/04/16-mediafrag-minutes.html#action06">http://www.w3.org/2009/04/16-mediafrag-minutes.html#action06</a>]<br />
|
|
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> Raphaël to ask
|
|
the Media Annotations WG to review our document [recorded in
|
|
<a href=
|
|
"http://www.w3.org/2009/04/16-mediafrag-minutes.html#action07">http://www.w3.org/2009/04/16-mediafrag-minutes.html#action07</a>]<br />
|
|
|
|
<strong>[NEW]</strong> <strong>ACTION:</strong> Yves to ask the
|
|
TAG whether transcoding should be forbidden or not when we send a
|
|
fragment of a resource [recorded in <a href=
|
|
"http://www.w3.org/2009/04/16-mediafrag-minutes.html#action01">http://www.w3.org/2009/04/16-mediafrag-minutes.html#action01</a>]<br />
|
|
|
|
<br />
|
|
[End of minutes]<br />
|
|
<hr />
|
|
|
|
<address>
|
|
Minutes formatted by David Booth's <a href=
|
|
"http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm">
|
|
scribe.perl</a> version 1.135 (<a href=
|
|
"http://dev.w3.org/cvsweb/2002/scribe/">CVS log</a>)<br />
|
|
$Date: 2009/04/17 19:32:10 $
|
|
</address>
|
|
|
|
</body>
|
|
</html>
|