Media Fragments Working Group Teleconference

 

 

<trackbot> Date: 23 September 2009

<raphael> Scribe: jackjansen

<raphael> Scrinenick: jackjansen

<raphael> scribenick: jackjansen

1 admin

<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

<mhausenblas> +1

<raphael> +1

Raphael: minutes approved

<silvia> +1

Thierry: action-111 is ongoing

2 UC & requirements

Raphael: 105 and 106 are ongoing, will try to do this afternoon

<raphael> ACTION-95?

<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

<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/95

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

<mhausenblas> +1

<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

<silvia> +1

3 specification

<raphael> ACTION-109?

<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

<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/109

<raphael> Yes, Silvia, this is Erik action we are talking about

Erik: 109 will be done this week

<raphael> ACTION-110?

<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

<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/110

<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

<raphael> http://lists.w3.org/Archives/Public/public-media-fragment/2009Sep/0133.html

<silvia> I just a few minutes ago sent an update on that discussion

<silvia> http://lists.w3.org/Archives/Public/public-media-fragment/2009Sep/0135.html

<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

Jack: agrees

<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 content-range
... using dimension:unit

<raphael> Range: <dimension>[':' <unit>] '=' <start time> - <end time>

conrad: units not optional

<Yves> +1 to no optional unit

+1

<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

beep beep

<raphael> Silvia, no objection ?

<silvia> no, I am not too worried about optional/non-optional unit in Range

<silvia> +1

<silvia> just curious about reasoning :)

<mhausenblas> +1

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?

<raphael> http://www.w3.org/2008/WebVideo/Fragments/wiki/Server-parsed_Fragments

<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.

4, test cases

<mhausenblas> http://www.w3.org/2008/WebVideo/Fragments/wiki/TestCases

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

<Yves> +1

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].

5 issues

Jack: no idea on issue 6

Yves: table it until Raphael is back

Tves: let's adjourn the meeting

ok, thanks!

Too many different syntaxes with rrsagent and zakim:-)

<Yves> yeah we should unify those ;)

<Yves> trackbot, end telcon