See also: IRC log
<trackbot> Date: 06 April 2011
<scribe> Scribe: raphael
<scribe> Scribenick: raphael
PROPOSED to accept the minutes of the last week telecon: http://www.w3.org/2011/03/23-mediafrag-minutes.html
<foolip> +1
+1
<davy> +1
minutes accepted
<Yves> +1
close ACTION-215
<trackbot> ACTION-215 Poke people and encourage them to join the telecons closed
ACTION-213?
<trackbot> ACTION-213 -- Silvia Pfeiffer to submit the proposed list of bugs to HTML5 -- due 2011-03-23 -- OPEN
<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/213
close ACTIOn-213
<trackbot> ACTION-213 Submit the proposed list of bugs to HTML5 closed
4 bugs now in the tracker
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10723
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12425
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12426
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12427
<foolip> not really
<foolip> (sorry, I'm muted)
<foolip> I've replied
<foolip> http://www.w3.org/Bugs/Public/show_bug.cgi?id=12426
UA test cases: http://www.w3.org/2008/WebVideo/Fragments/TC/ua-test-cases.html
Server test cases: http://www.w3.org/2008/WebVideo/Fragments/TC/server-test-cases.html
Jack: test cases are made for testing the spec and not for particular implementations
Philip: what does it mean? test cases are made for implementations
Jack: no, because test cases are made for making sure the wording of the spec can at least be interpreted the same way by 2 different people
Davy: I also think we should not battle for this, we mean roughly the same thing
<Yves> well, it's those corner cases that are important, testing the spec by implementing is indeed to see if people got the same reading, but also if the coverage of the issue raised by implementation is good enough in the spec
Davy: let's start for the UA test cases
URI:
http://www.w3.org/2008/WebVideo/Fragments/TC/ua-test-cases.html
... we have 60 Test Cases
Davy: I will go over the list of TC, and you should shout if you disagree
<davy> http://www.w3.org/2008/WebVideo/Fragments/TC/ua-test-cases#TC0001-UA
<foolip> npttimedef = [ deftimeformat ":"] ( npttime [ "," npttime ] ) / ( "," npttime )
<foolip> http://www.w3.org/TR/media-frags/#naming-time
TC1 is wrong ... syntax is invalid
scribe: it should be equivalent
to TC27
... but we should test it
<davy> http://www.w3.org/2008/WebVideo/Fragments/TC/ua-test-cases#TC0002-UA
Philip: I also disagree on this one ... I think it should be an error
Jack: no, since the intervals are half-open
Philip: it means that it will be a still image?
Jack: no, it means TC2 and TC3
are equivalent
... start of the interval is inclusive, and end of the interval
is exclusive
<Yves> TC2 with start=end mean display this point in time (one picture in a video?)
Should we enforce e>s
Philip: it is also reasonable to have e=s
Jack: I think I would prefer half-open intervals
Raphael: but Jack, is [3,3) valid?
Philip: I think it should be
considered as an invalid range
... so the whole resource should be requested
... the UA has detected with its logic that this is an invalid
range
Davy: instead of requesting the whole resource, we could just request the include-setup
Philip: this is the general
problem of what to do with invalid range
... again similar to TC27
Raphael: Philip and Davy prefer
to request the whole resource
... Silvia will perhaps prefer to request only the setup
data
... Jack does not care, Yves has a slight preference to display
a still image but just want we specify what should it be
Philip: I think we should just ignore invalid ranges to simplify implementations
<jackjansen> I don't care, but I agree with Yves that we should specify it.
Raphael: TC2, TC3, TC27 (and perhaps other TC) will request the entire resource ... except if Silvia strongly disagree
http://www.w3.org/2008/WebVideo/Fragments/TC/ua-test-cases#TC0003-UA
<scribe> done
<davy_> http://www.w3.org/2008/WebVideo/Fragments/TC/ua-test-cases#TC0004-UA
<davy_> http://www.w3.org/2008/WebVideo/Fragments/TC/ua-test-cases#TC0008-UA
<davy_> http://www.w3.org/2008/WebVideo/Fragments/TC/ua-test-cases#TC0013-UA
<Yves> you can't know in advance that you are requesting the whole resource, right?
<foolip> Range: bytes=x-y
Davy: I can add a 4th option with a Range request expressed in bytes
Philip: we should not specify all the possible ways, but just make sure we can request byte ranges request for TC4
Raphael: for TC4, add the possibility to issue a Range request expressed in bytes
http://www.w3.org/2008/WebVideo/Fragments/TC/ua-test-cases#TC0005-UA
Philip: the byte ranges could be
different
... should we just write x-y ?
Jack: I'm concerned about
readability of the table
... so we could add at the top this is just possible
outcomes
... for the byte ranges requests (depending on how UA caches
things anyway)
Philip: we should also add on the top of the table that we could have a number of range requests (not a single one)
Davy: the column 4 meant that either the UA has knowledge about the media or it has not ... it does say how he got this information
Jack: will this column 4 be used
for automatic testing ?
... if yes, then Philip's implementation will fail on all test
cases
Davy: we just ignore the first
request of Philip's implementation
... the include-setup one
... is it important that we log/check the HTTP request?
... is it important how the UA get the MF visualization
right?
Philip: checking the HTTP implementation is secondary, we absolutely need to test the playback behavior
<Yves> main thing is defining the semantic of the #frag, then the http interaction is optional
Raphael: my UA download the entire resource and just seek to the start of the fragment on client side, and stop playing at the end of the fragment ... is this a conforming implementation ?
Yves: we need to check the playback in the UA, not the network
Jack: servers might not be MF compliant and the UA should not be penalized
Raphael: it's noon, thanks all
for attending
... are you all here next week
ALL: yes
Next week, we keep discussing all TC, that will include the changes of Davy!
Round of applause for his work
Meeting adjourned