See also: IRC log
<trackbot> Date: 13 May 2009
<Gui> yes
<raphael> Scribe: Guillaume
<raphael> Scribenick: yes
<mhausenblas> Scribenick: Gui
<raphael> Minutes: http://www.w3.org/2009/04/29-mediafrag-minutes.html
<raphael> +1
<mhausenblas> +1
Accepting minutes
<silvia> +1
Ok, minutes of the 29 April 2009 telecom accepted
<raphael> Summary: unlikely that Conrad, Silvia and Guillaume can make the Amsterdam meeting
<raphael> ... easier for Europeans (Michael, Jack, Raphael, what about Yves?)
The working draft has been published
All actions arel ongoing
TOPIC UA Server HTTP Communication
Conrad will discuss this at the next teleconf
We need to start capturing what we recommend regarding the use of "?" and "#"
Silvia is getting inputs from the HTML5 mailing-list, any specific information that's relevant we should look at? Silvia and Conrad please keep track.
<raphael> Raphael: in the next iteration of the document, we should clearly clarify the role of '#' and '?'
Further discussions about the MF syntax giving absolute times mechanism. It is a big requirement. Silvia to continue discuss with Thomas.
<raphael> http://www.w3.org/2008/WebVideo/Fragments/wiki/UserAgentMediaFragmentResolution
Michael would like to take us through the document at some point.
In the sequence of things, two things needs to be explained :
the template of HTTP headers
<raphael> http://www.w3.org/2008/WebVideo/Fragments/wiki/UA_Server_RTSP_Communication
<silvia> http://www.ietf.org/rfc/rfc2326.txt <- rtsp spec
<silvia> http://www.w3.org/2008/WebVideo/Fragments/wiki/Image:Rtsp.jpg <- synchronise this picture with more details with the one for http
<mhausenblas> thanks silvia
<silvia> :)
Discussing the issues raised on the mailing list
e.g. t=10,
Is it good syntax or not?
Do we need to specify the media type as well for each test case?
1. the way to express the media type in the fragment syntax (only the server would need to know)
2. Write the media type inside the Test case results
(We need this data to be able to report on the test cases)
<raphael> trackbot, status
ISSUE: Should we have the media type inside the Test Cases?
<trackbot> Created ISSUE-9 - Should we have the media type inside the Test Cases? ; please complete additional details at http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/9/edit .
Let's go through each test case and spend one or two minute on each during a teleconf (now?)
<mhausenblas> +1
<conrad> +1
<raphael> TC0000: http://www.w3.org/2008/WebVideo/Fragments/wiki/TestCases#TC0000:_empty_MF: reviewed and agreed
TC empty MF - Is there cases where the MF conforming UAs would behave differently?
<silvia> +1
<silvia> no
TC0001: undefined time segment - npt - Would we expect an output?
Do we agree that the output should be the entire resource?
it should be unspecified?
<silvia> I agree - it should be the entire resource
<conrad> TC0001: +1
<mhausenblas> Scribenick: mhausenblas
RESOLUTION: TC0001 accepted as proposed
<Gui_> TC0002: empty time segment - npt
<silvia> #t=0,0 could be written as #t=x,x
<scribe> Scribenick: Gui_
#t=x,x, where x=x
<conrad> i think that in barcelona we were talking about a zero-duration media file as the output of this
<silvia> where x is integer
Can a "zero duration media" be returned?
The resource exists, it's just that we return an empty fragment of it
Should we be returning a frame as empty content?
What is the purpose, a blank screen for Video, what about the case of Audio?
Maybe this is useful as "place holders"
Either we signal to the client that's it's a error (it's not allowed to do it) or it should be for some usage
It could be in the content header, Content not acceptable 406 or 416 the requested range is not satisfiable
<silvia> I think: 416 Requested Range Not Satisfiable
<raphael> I think too Silvia
<mhausenblas> ACTION: Michael to summarise the options for 4xx status code for empty TC0002-0007 in a Wiki page [recorded in http://www.w3.org/2009/05/13-mediafrag-minutes.html#action01]
<trackbot> Created ACTION-79 - Summarise the options for 4xx status code for empty TC0002-0007 in a Wiki page [on Michael Hausenblas - due 2009-05-20].
For all the TC returning EMPTY, what should the response be to the UA be (see HTTP codes)?
<conrad> i think 416 if and only if the fragment range was given in an HTTP Range request header; a different error notification method otherwise :-)
We need to have these resolutions (on which HTTP codes we decide to use) written down
<silvia> conrad: I assumed that, too
<conrad> eg. #track= will not be handled through Range request
<mhausenblas> RESOLVED: The WG agrees that empty is not an error (as in 404) but a recoverable state
Summarize what would the different responses be depending on the request (range request, others)
<conrad> i agree with silvia
If the UA request a fragment of the entire duration, it should get notified with 206
<conrad> but 200 for TC0
thanks conrad
<conrad> +1
<conrad> client should ignore stupid request and not bother wasting the server's time
RESOLUTION: We agree that the HTTP response code should be 200 for TC0000
RESOLUTION: We agree that the HTTP response code should be 200 for TC0000, TC0001 should be 200 and the UA strip what's behind the #
For TC0002-6, Michael as an action
<mhausenblas> so that #t=, -> # which makes TC0001 == TC0000 ;)
RESOLUTION: The WG agrees that empty responses is NOT an error, so it's not a 404
<conrad> +1 mhausenblas (and if we don't specify the details, implementers will choose arbitrarily :)
It takes a long time to go through the TC, we need to continue doing so. Michael, with our resolutions, will be able to reflect changes on the Wiki. Thanks Michael
<mhausenblas> ;) true, conrad. sad but true ;)
we are running out of time, and closing the teleconf for today.
Nothing futher to discuss? no!
<conrad> ok!
<silvia> cool :)
<conrad> thanks all :-)
Thanks you everyone! Have a nice week!
Bye
<mhausenblas> [adjourned]
<mhausenblas> hang on
trackbot, status
