See also: IRC log
<trackbot> Date: 23 September 2009
<raphael> Scribe: jackjansen
<raphael> Scrinenick: jackjansen
<raphael> scribenick: jackjansen
<raphael> Minutes telecon: http://www.w3.org/2009/09/09-mediafrag-minutes.html
<raphael> Minutes F2F: http://www.w3.org/2009/09/17-mediafrag-minutes.html and http://www.w3.org/2009/09/18-mediafrag-minutes.html
Raphael: minutes approved
Thierry: action-111 is ongoing
Raphael: 105 and 106 are ongoing, will try to do this afternoon
<trackbot> ACTION-95 -- Michael Hausenblas to review ALL UC with a mobile hat on and check whether these sufficiently cover the mobile usage -- due 2009-09-02 -- OPEN
Michael: on 95 there seem to be no issues with mobile
RESOLUTION: 95, no special issues for mobile
<raphael> Side Conditions are in 2 documents: http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/#side-conditions
<raphael> which document should it be?
<raphael> close ACTION-95
<trackbot> ACTION-95 Review ALL UC with a mobile hat on and check whether these sufficiently cover the mobile usage closed
<raphael> Jack: I agree it should be in one document, no preference
Raphael: tends to think its requirement doc
<scribe> ACTION: Raphael to move section to requirements doc only [recorded in http://www.w3.org/2009/09/23-mediafrag-minutes.html#action01]
<trackbot> Sorry, couldn't find user - Raphael
<raphael> Silvia: about your suggestion of removing the side conditions section in one of the two document
<scribe> ACTION: troncy to move section to requirements doc only [recorded in http://www.w3.org/2009/09/23-mediafrag-minutes.html#action02]
<trackbot> Created ACTION-113 - Move section to requirements doc only [on Raphaël Troncy - due 2009-09-30].
<raphael> ... we will remove it from the spec and keep it in the requirements doc
<trackbot> ACTION-109 -- Erik Mannens to and Davy to write a paragraph in the documents to explain why we don't include this feature in the spec (rationale) based on the group analysis (impact both req and spec documents) -- due 2009-09-24 -- OPEN
<raphael> Yes, Silvia, this is Erik action we are talking about
Erik: 109 will be done this week
<trackbot> ACTION-110 -- Silvia Pfeiffer to silvia to Draft a summary starting from her blog post and the 17/09/2009 IRC minutes in the document (role of ? and #) -- due 2009-09-24 -- OPEN
<silvia> 110 will be done this week
<raphael> ... what's the status of this action?
<silvia> not done yet
Silvia: 110 also this week
Raphael: let's talk about range syntax
<silvia> I just a few minutes ago sent an update on that discussion
<silvia> does anyone have the specification that Yves pointed out will update the RFC to satisfy the need for other range types?
<conrad> if we are going to make a spec for time range units, i agree with silvia's proposal that both Range request header and Content-Range response header should use "time:npt" etc.
<conrad> if we start re-using parsers then we need to have the same syntax constraints in both
<conrad> eg. commas have a special meaning in headers
Jack: prefres to stay close to existing http syntax
<silvia> we are not making any differences to existing http syntax
Conrad: also syntax in different http headers
<silvia> the RFC has been reviewed: http://tools.ietf.org/wg/httpbis/trac/ticket/85
<silvia> one change was "make name of header value production for "Range" consistent with other headers"
Raphael: proposed resolution:
adopt proposal from Silvia, with both range and
... using dimension:unit
<raphael> Range: <dimension>[':' <unit>] '=' <start time> - <end time>
conrad: units not optional
<Yves> +1 to no optional unit
<raphael> Range: <dimension> ':' <unit> '=' <start time> - <end time>
<raphael> same for Content-Range
<silvia> why no optional unit?
<conrad> if any of the time are allowed to have frame offsets, the unit must be there
Raphael: revised proposal: units not optional, same for content-range
<raphael> +1 for this proposal
<raphael> silvia, if the offset is at the frame precision, then unit is mandatory
<Yves> silvia, because machines are not humans
<raphael> Silvia, no objection ?
<silvia> no, I am not too worried about optional/non-optional unit in Range
<silvia> just curious about reasoning :)
RESOLUTION: range and unit are non-optional in content-range and range headers
<silvia> btw: the draft RFC update is here http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-07#page-8
Raphael: next, should we use range for addressing tracks?
<conrad> silvia: what is your response about use of range for track?
Raphael: Conrad wants new header, Silvia wants to reuse range
Yves: range header is mainly numeric
<silvia> I wonder why we need a different header for that - let me read up on the email thread
Yves: we will wait for raphael to return
<silvia> so, Yves, do you agree about creating a new "Fragment:" header for tracks?
<conrad> you can't take an interval of track names, or describe the instance-length for Content-Range
We will continue.
<silvia> you could if the tracks were ordered
<silvia> then the "instance-length" could be the number of tracks
Yves: if we have it in range, would we need resolver to map track names to byte ranges?
<silvia> we need such a resolver for time, too
<conrad> silvia: how do you request "t=20/20&track=audio" as a Range header, and how do you make the Content-Range response?
Yves: anyone has any response to my question?
<silvia> multiple Range headers
Jack: no opinion
<silvia> multiple Content-Range response headers
<Yves> multiple content ranges are allowed
Yves: there is a similarity to what we said about aspect ratio
<Yves> is track as a #fragment really required?
<silvia> can you explain the similarity that you see?
<Yves> when a URI can be contructed with the relevantstarting/ending time
Should we table this until next week, silvia?
<Yves> having named tracks instead of numeric value adds unnecessary complexity that requires a resolver, or a way to enumerate all the tracks in order
<silvia> I do believe the track and also the id issues aren't fully understood yet
<silvia> I also believe that it is good to focus on solving the "time" specification and protocol procedure now, but the others can wait a bit
<conrad> Yves, that relates to ISSUE-4
<silvia> we could indeed keep discussing this on the mailing list until we have the spec for "time" finalised
Yves: table, discuss on mail or next week.
Michael: on action 93, it doesn't seem to affect anything
RESOLUTION: action-93, no test cases were affected
<mhausenblas> close ACTION-93
<trackbot> ACTION-93 Revisit the TC and see which are effected by the temporal-optional-comma-decision closed
Michael: remove test case 4, as aspect ratio is gone
ACTION on Michael to remove it
<trackbot> Sorry, couldn't find user - on
ACTION Michael to remove test case 4
<trackbot> Created ACTION-114 - Remove test case 4 [on Michael Hausenblas - due 2009-09-30].
<mhausenblas> state semantics http://www.w3.org/2008/WebVideo/Fragments/TC/mftc
Michael: on to action 108
<mhausenblas> Michael: empty means that it is defined but yields empty representation
Michael: looking at naming of
test cases, empty versus undefined
... is inconsistent, will clean it up
... empty means - defined, but yields empty representation
<mhausenblas> two main categories: defined or undefined
Michael: undefined means - no range given
<mhausenblas> empty is defined, but yields empty representation
ACTION Michael to come up with categorization of test cases wrt empty, undefined, etc
<trackbot> Created ACTION-115 - Come up with categorization of test cases wrt empty, undefined, etc [on Michael Hausenblas - due 2009-09-30].
Jack: no idea on issue 6
Yves: table it until Raphael is back
Tves: let's adjourn the meeting
Too many different syntaxes with rrsagent and zakim:-)
<Yves> yeah we should unify those ;)
<Yves> trackbot, end telcon