See also: IRC log
<trackbot> Date: 17 November 2010
trackbot, start telecon
<trackbot> Meeting: Media Fragments Working Group Teleconference
<trackbot> Date: 17 November 2010
<tomayac> hamburg, germany, yes
<scribe> Scribe: Raphael
<scribe> Scribenick: raphael
PROPOSED to accept the minutes of the 7th F2F meeting:
<erik> +1 (but am still reading it though :)
<tomayac> pass ;-)
For IBBT ...
<trackbot> ACTION-192 -- Davy Van Deursen to update the specification to state what the processing should do when media fragments request (time dimension) does not match exactly how the media item has been encoded -- due 2010-11-08 -- OPEN
<trackbot> ACTION-193 -- Erik Mannens to make a schema for the server redirect recipe -- due 2010-11-08 -- OPEN
<trackbot> ACTION-195 -- Davy Van Deursen to add a paragraph in the section 7.1 to specify that video, audio, img or any href is all treated similarly (range request issued when facing a media fragment) -- due 2010-11-08 -- OPEN
<trackbot> ACTION-191 -- Yves Lafon to update the production rules of the time dimension with the npt format for making the hours optional -- due 2010-11-08 -- OPEN
Yves started to do it during the f2f meeting, needs to add a sentence in the spec
<trackbot> ISSUE-19 -- Parsing must be defined normatively in the MF spec itself -- open
Philip has proposed a number of patches, see result at http://people.opera.com/philipj/2010/11/04/media-fragments-spec/overview.html
Yves has discussed this with Philip which sort of outdate this proposal
Yves: the result is that we
should keep the grammar as it is, + some clarification text on
the purpose of the grammar
... + a normative algorithm for parsing
... we need consensus and approval from Jack, Silvia, and Davy at least in the group + feedback from the implementers
<silvia> is the proposal formally specified somewhere?
<silvia> I'm probably ok with it but don't want to give a blind vote
Raphael: what this clarification text should express?
<Yves> the purpose of the grammar is to describe the "normal" syntax, ie: the one that should be created
<Yves> ie: it is not the parsing rules
Raphael: where we should write this ?
Yves: at the beginning of section
4 and appendix D
... as a reminder
<scribe> ACTION: raphael to add a clarification text regarding the purpose of the grammar [recorded in http://www.w3.org/2010/11/17-mediafrag-minutes.html#action01]
<trackbot> Sorry, couldn't find user - raphael
<scribe> ACTION: troncy to add a clarification text regarding the purpose of the grammar [recorded in http://www.w3.org/2010/11/17-mediafrag-minutes.html#action02]
<trackbot> Created ACTION-199 - Add a clarification text regarding the purpose of the grammar [on Raphaël Troncy - due 2010-11-24].
Raphael: regarding the parsing algorithm
Yves: back to a very detailed
description of the algorithm
... I would like to read it crisp and procedural
... we need an agreement that the parsing algorithm become normative
... I would agree that given this clarification of role, the algorithm become normative
Erik: I agree too
Silvia, would you have any objection of having a detailed parsing algorithm of a media fragment URI nomative in the spec instead of an annex?
Two versions of the algorithm
... 2/ http://people.opera.com/philipj/2010/11/04/media-fragments-spec/overview.html#processing-name-value-components
... and http://people.opera.com/philipj/2010/11/04/media-fragments-spec/overview.html#processing-name-value-components
... and http://people.opera.com/philipj/2010/11/04/media-fragments-spec/overview.html#processing-name-value-lists
<silvia> no objection here
Raphael: I agree to ask Philip to
put which version he prefers
... the only contentious issue might be: 2.
2. Otherwise, the name-value pair does not represent a media fragment dimension. Validators should emit a warning. User agents must ignore the name-value pair.
Note: Because the name-value pairs are processed in order, the last valid occurence of any dimension is the one that is used.
Raphael: Validators should
perhaps emit an error rather a warning ?
... the processing order of the dimensions and whether parsing should be relaxed or not in case of multiple occurences of the same dimension (except track)
<scribe> ACTION: troncy to send a proposal to close ISSUE-19 that consists in: clarification text + normative parsing algorithm [recorded in http://www.w3.org/2010/11/17-mediafrag-minutes.html#action03]
<trackbot> Created ACTION-200 - Send a proposal to close ISSUE-19 that consists in: clarification text + normative parsing algorithm [on Raphaël Troncy - due 2010-11-24].
<foolip> I prefer my latest version that uses the namevalues syntax
great, thanks Philip, we will use this one then :-)
Raphael: started by a thread from
... discussed at the F2F meeting: http://www.w3.org/2010/11/02-mediafrag-minutes.html#item05
... lead to the notion of optimistic use of the Range header, only for the 'second' unit
... it cannot be done for any other way for getting part of the content
<silvia> (except that my email was about something completely different ;-)
<Yves> yeah I think Silvia's email was about using the html fragment for video
<Yves> which by default is => no (ie: it's per page, so you can't generalize this)
<silvia> it was not to become normative - the idea is to propose a syntax that people can choose to make use of
<silvia> because the html URI is much more important for most video on the web than the video URI
Yves: there are 2 orthogonal
... the fragment applies to ONE resource you're retrieving
... the other issue of optimistic use of the Range header, Philip states that this is up to the URI spec to change
... I quote: "The semantics of the fragment identifier is defined by each MIME type registration. Before we know the type, we can't assume anything. Therefore, the only possibility is if the URL/URI/IRI spec itself states that #t=1 has some semantics for *all* types and that this should cause headers Foo and Bar to be sent. However, I truly doubt we'll see media-specific things like this put into URL/URI/IRI, it's seems like a gigantic layering violat
<silvia> as I said: the idea is to give a Web developer that wants to do media fragments on a Web page a recommendation for how to do the URI structure on their page - they still have to implement it themselves, it's just handy to agree on the same approach
<silvia> no need for more Range headers, or an implementation in browsers or anything - just a helping hand for Web developers
Raphael: I agree silvia, and I strongly recommend to add a new Appendix for what you propose, note to developers :-)
<foolip> Agreed, as long as there's no change in UA behavior for #t=1 for HTML I'm fine with recommending web developers to use the syntax
<silvia> btw: all the video hosting sites already have such approaches in the URIs so it's not theoretic
<Yves> I agree that we can't assume anything, and we shouldn't break any layer, but if we know enogh context, using Range request with a unit that can only be applied to the media type we are targeting (and will default to normal behaviour for all the others)
<Yves> is a (not nice) possible optimisation
<silvia> yup, no problem
<silvia> just don't know when I'll get around to it :)
<Yves> context should be that URI is in a <video> tag
Raphael: it is part of my action to clarify the use of optimistic use of Range header optimization in case we are in the right context <audio> or <video> element
Erik: what is the schedule?
Raphael: finish all actions in
the tracker by the end of the month, so we can transition to
... have a telecon about test cases afterwards, for preparing the exit CR stage
<erik> horay for Thomas!
<tomayac> thanks :-)
Raphael: we have discussed Ken
... from YouTube
<tomayac> funny enough ken and me have already been in contact with regards to YT closed captions. i'll catch up with him and let him know about recent developments.