minutes of 2009-09-23 teleconference

Dear all,

[Apologies for my sudden drop, fire trials in the building have 
unexpectedly close power supply and disconnect us from the network, 
impacting internet connexion and phone (because of vo-ip) :-(]

The full minutes are available for review at 
http://www.w3.org/2009/09/23-mediafrag-minutes.html (and in text format 
below).

I think the main resolution taken concern the syntax for Range and 
Content-Range headers. I have slightly updated the syntax as:

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

  Content-Range: <dimension> [':' <unit>] ' ' <real-start-pos> '-' 
<real-end-pos> '/' (<instance-length> / "*" )

also at 
http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions#Media_Fragment_Headers

Note that I follow the version 07 of the HTTBis draft that says that the 
instance-length could also be '*' in the Content-Range response, meaning:

    The header SHOULD indicate the total length of the full entity-body,
    unless this length is unknown or difficult to determine.  The
    asterisk "*" character means that the instance-length is unknown at
    the time when the response was generated.

Feel free to shout if you have any objections.

I also understand from the minutes that we still need to discuss how 
will handle media fragments for the 'track' and 'name' dimensions, and 
in particular which headers should we use. I understand also that it is 
less of priority as we should first get quickly the draft out for the 
two other numerical dimensions. I will write this topic in the 
forthcoming agendas of our telecon.
Cheers.

   Erik & Raphaël

------
    [1]W3C
       [1] http://www.w3.org/
                                - DRAFT -
              Media Fragments Working Group Teleconference
23 Sep 2009
    [2]Agenda
       [2] 
http://lists.w3.org/Archives/Public/public-media-fragment/2009Sep/0129.html
    See also: [3]IRC log
       [3] http://www.w3.org/2009/09/23-mediafrag-irc
Attendees
    Present
           Conrad, Jack, Michael, Silvia, Raphael, Thierry, Yves, Erik
    Regrets
    Chair
           Erik, Raphael
    Scribe
           jackjansen
Contents

      * [4]Topics
          1. [5]1 admin
          2. [6]2 UC & requirements
          3. [7]3 specification
          4. [8]4, test cases
          5. [9]5 issues
      * [10]Summary of Action Items
      _________________________________________________________



    <trackbot> Date: 23 September 2009

    <raphael> Scribe: jackjansen

    <raphael> Scrinenick: jackjansen

    <raphael> scribenick: jackjansen

1 admin

    <raphael> Minutes telecon:
    [11]http://www.w3.org/2009/09/09-mediafrag-minutes.html

      [11] http://www.w3.org/2009/09/09-mediafrag-minutes.html

    <raphael> Minutes F2F:
    [12]http://www.w3.org/2009/09/17-mediafrag-minutes.html and
    [13]http://www.w3.org/2009/09/18-mediafrag-minutes.html

      [12] http://www.w3.org/2009/09/17-mediafrag-minutes.html
      [13] 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>
    [14]http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/95

      [14] 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:
    [15]http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-req
    s/#side-conditions

      [15] 
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
    [16]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
    [17]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>
    [18]http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/109

      [18] 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>
    [19]http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/110

      [19] 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>
    [20]http://lists.w3.org/Archives/Public/public-media-fragment/2009Se
    p/0133.html

      [20] 
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>
    [21]http://lists.w3.org/Archives/Public/public-media-fragment/2009Se
    p/0135.html

      [21] 
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:
    [22]http://tools.ietf.org/wg/httpbis/trac/ticket/85

      [22] 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
    [23]http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-07#page-8

      [23] http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-07#page-8

    Raphael: next, should we use range for addressing tracks?

    <raphael>
    [24]http://www.w3.org/2008/WebVideo/Fragments/wiki/Server-parsed_Fra
    gments

      [24] 
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>
    [25]http://www.w3.org/2008/WebVideo/Fragments/wiki/TestCases

      [25] 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
    [26]http://www.w3.org/2008/WebVideo/Fragments/TC/mftc

      [26] 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

Summary of Action Items

    [NEW] ACTION: Raphael to move section to requirements doc only
    [recorded in
    [27]http://www.w3.org/2009/09/23-mediafrag-minutes.html#action01]
    [NEW] ACTION: troncy to move section to requirements doc only
    [recorded in
    [28]http://www.w3.org/2009/09/23-mediafrag-minutes.html#action02]

    [End of minutes]

-- 
Raphaël Troncy
EURECOM, Multimedia Communications Department
2229, route des Crêtes, 06560 Sophia Antipolis, France.
e-mail: raphael.troncy@eurecom.fr & raphael.troncy@gmail.com
Tel: +33 (0)4 - 9300 8242
Fax: +33 (0)4 - 9000 8200
Web: http://www.cwi.nl/~troncy/

Received on Wednesday, 23 September 2009 11:43:52 UTC