W3C home > Mailing lists > Public > public-media-fragment@w3.org > December 2009

minutes of 2009-12-02 teleconference

From: RaphaŽl Troncy <Raphael.Troncy@cwi.nl>
Date: Wed, 02 Dec 2009 22:18:49 +0100
Message-ID: <4B16D9B9.2060804@cwi.nl>
To: Media Fragment <public-media-fragment@w3.org>
Dear all,

The minutes of today's telecon (02/11/09) are available at 
http://www.w3.org/2009/12/02-mediafrag-minutes.html and in a text format 


       [1] http://www.w3.org/
              Media Fragments Working Group Teleconference
02 Dec 2009
    See also: [3]IRC log
       [3] http://www.w3.org/2009/12/02-mediafrag-irc
           Raphael, Silvia, Yves, Philip_(irc), Michael
           Erik, Davy, Jack

      * [4]Topics
          1. [5]Specification
          2. [6]Specific (cont.) - 2 roundtrips
          3. [7]Rework of the section 5
      * [8]Summary of Action Items

    <trackbot> Date: 02 December 2009

    <scribe> Scribe: Yves

    <raphael> Minutes from last week:

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

    <raphael> +1 for accepting

    no objection => accepted

    <silvia> +1


    <raphael> ACTION-112?

    <trackbot> ACTION-112 -- RaphaŽl Troncy to propose a digest of
    Conrad and current's proposal regarding the use of existing and
    custom headers for the communication UA server -- due 2009-09-25 --


      [10] http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/112

    We have the one round trip version, and the two round trips versions

    <raphael> close ACTION-112

    <trackbot> ACTION-112 Propose a digest of Conrad and current's
    proposal regarding the use of existing and custom headers for the
    communication UA server closed

    Yves: what make you think that the one-round trip version can't be

    Raphael: implementation issue only, current implementation can't
    without knowing the unit

    Yves: right, but implementation can't exist before the spec is ready

    Raphael: we can then document expectation on client servers and
    proxies (wrt support/implementation)

    Yves: that would do it

    <raphael> Silvia: there is a optimal solution and then divergent
    cases ... this is how section 3 is written

    <raphael> Yves: changing the UA is not easy

    Silvia: changing servers and clients is easy, proxies are not easy
    to update

    Yves: By proxy you mean caches, proxies will work perfectly well

    <silvia> I mean caching proxies indeed

    <foolip> request to speak (write)

    <raphael> Raphael: indeed my asumption is that we have a UA
    conformant to the media fragment spec (parse), a server like Davy's
    one that support MF URI and that's it

    Yves: just to mention that I am not against the two round trip
    approach :)

    <raphael> ... i.e. no caches have been modified

    <raphael> Raphael: do you agree that the 2 round-trips approach
    allow to cache fragments without changing cache implementation ?



    GET /2008/WebVideo/Fragments/media/fragf2f.mp4 HTTP/1.1

    Host: www.w3.org

    Accept: video/*

    Fragment: time:npt=12-21

    <raphael> Yves: time ranges are cacheable but need implementation. 2
    rounds trip is a hack to allow current proxies to cache

    HTTP 200 OK

    Content-Length: 3571437

    Content-Fragment: time:npt=12-21

    Vary: Fragment

    we should add Content-Location:

    <raphael> Yves: in Conrad's proposal, case 1.2.b, we need to add a
    Content-Location header in the response

    <foolip> is there a speaker queue?

    <raphael> yes, Philip

    <raphael> Yves: my concern is that in the case of Conrad's proposal,
    if you have 2 request, the second one will flush the cache of the
    first one

    <foolip> I would like to note that the NPT syntax in the HTTP
    headers examples are inconsistent. Would it not be best to define a
    normalized form? The UA would have to pick a formatting anyway
    unless it just copies it verbatim (in which case it doesn't actually
    know which offset it is requesting or if it's valid syntax).

    <raphael> Philip, can you point us to this inconsistency ?

    <raphael> I don't see it

    <foolip> "time:npt 11.85-21.16/36" vs "time:npt=12-21"

    ah it's the range reply syntax

    which is starting time -end time / total time

    you have the same asymetry in byte ranges

    <foolip> in either case, NPT should be normalized, so that it isn't
    sometimes 0:00:12, sometimes 12 and sometimes 12s

    <raphael> Philip: we follow the same pattern that the bytes range
    request ... with a dissimetry between request and response

    <raphael> it is not 0:00:12

    <raphael> where did you see this Philip ?

    <foolip> raphael: some more zeroes?

    <silvia> foolip: the syntax is given in


    <raphael> I thought I have normallized the npt syntax

    <silvia> foolip: if something does not conform to that syntax, it is
    a typo

    <raphael> Section 5 contains indeed typos

    <foolip> so which format is normalized?

    <silvia> I think section 5 still needs a general work-over

    <foolip> the ABNF allows any kind of variation

    <foolip> not any, but many variations of the same time

    <silvia> ah, yes, we decided to give the user the freedom to specify
    relatively freely, but the syntax on the wire is fixed

    <foolip> that's good, where is it defined?

    <silvia> not yet in the spec - needs to go into section 5

    <foolip> ok, so we are already in agreement that this is neeed

    <foolip> needed

    <foolip> good

    <silvia> yup, indeed

    <foolip> I suggest normalizing to seconds without s, but that's just

    <foolip> anything is fine

    <foolip> as long as there can only be one possible string output for
    each input (makes writing conformance test suites lot easier too)

    <silvia> yes, indeed

    <raphael> OK, philip, I try to solve your problem ...

    <foolip> thanks

    <raphael> what do you would like to be changed in the spec?

    <raphael> I'm not sure I understand it :-(

    <raphael> 1) The Media Fragment URI syntax ? 2) The HTTP request
    header syntax ? 3) The HTTP response header ?

    <foolip> it should say that when sending header X, the format MUST
    be Y, with Y unambiguously defined

    <raphael> ... for example in the case of npt

    <foolip> 2 and 3

    <foolip> 1) is the parsing end, which we'll get to later I think

    <foolip> this should be a conformance requirement of both UAs and

    <raphael> OK Philip, now I understand, indeed, we haven't specified
    yet the syntax for 2) and 3)

    <raphael> The only things we have:


    <foolip> OK, then it's just a matter of time, I shall not worry any
    more :)

    <raphael> +1

    <raphael> ... or worry later

    Silvia, we need some ABNF there as well

    Yves: to summarize, lax URI syntax, strict header

    <silvia> part of the syntax was started in



      [15] http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-08

    <silvia> but needs to go into ABNF

    <raphael> Silvia, yes, it is even better summarized in




    other-ranges-specifier = other-range-unit "=" other-range-set

    other-range-set = 1*CHAR

    other-range-unit = token

    <scribe> ACTION: Yves to come up with ABNF for header syntax
    [recorded in

    <trackbot> Created ACTION-123 - Come up with ABNF for header syntax
    [on Yves Lafon - due 2009-12-09].

    <foolip> ABNF syntax without any use of " / " to that.

Specific (cont.) - 2 roundtrips

    Yves: on the two round trip I have some reservation with the first
    200 OK reply

    <raphael> Yves: In the case of 2.1, first roundtrip response should
    be a 307 instead of 200

    may be better to have a 307 and redirect to itself with the right

    will followup by email

    Raphael: we need to update section 5

    Silvia: happy to work on it

Rework of the section 5

    <raphael> See:


    Silvia: what you summarized is in sync with what I had in mind,
    writing this will clarify things
    ... not clear that we need the Fragment: header, but don't remember
    what Conrad wanted it for
    ... but good that the email thread restarted

    Raphael: I proposed a restructuration plan for section 5

    <mhausenblas> +1

    Raphael: Silvia, do you want to work on specific sections? or all of

    Silvia: better if it is consistent

    <scribe> ACTION: Silvia to rework section 5 according to Raphael's
    restructuration plan
    c/0009.html due 2009-12-15 [recorded in


    <trackbot> Created ACTION-124 - Rework section 5 according to
    Raphael's restructuration plan
    c/0009.html due 2009-12-15 [on Silvia Pfeiffer - due 2009-12-09].


    <foolip> where in section 5 will the processing requirements
    (parsing) go? part of MF resolution?

    depends on the author :)

    <silvia> I think it should be section 5.5 ABNF for HTTPrequest &
    response headers

    <scribe> ACTION: Michael to revisit his ednote in section 5
    [recorded in

    <trackbot> Created ACTION-125 - Revisit his ednote in section 5 [on
    Michael Hausenblas - due 2009-12-09].

    <foolip> I agree that most parts can be given as ABNF, but not all
    of it

    <foolip> I can elaborate if it's not clear why.

    <silvia> why not?

    <raphael> Yes please Philip, I suggest we wait for Silvia's input
    and then complain what is not sufficiently specified

    Raphael: on the test cases, lots of action. postpone?

    <foolip> sorry, difficult to guess who's talking over IRC

    <scribe> => postponed

    <raphael> ACTION-119?

    <trackbot> ACTION-119 -- Yves Lafon to request admins to set up a
    cvs notifications mailing list and notifications -- due 2009-10-14
    -- OPEN


      [24] http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/119

    Yves: oops, will work on this

    <silvia> foolip, can you clarify your opinion on ABNF via email?

    <foolip> silvia: to you or the list?

    <silvia> the list

    <foolip> will do


    tracker, end telcon

    <raphael> Raphael: I will make sure we follow-up the current thread
    of dicussion so we can converge rapidly between Conrad's and
    current's proposal

    trackbot, end telcon

Summary of Action Items

    [NEW] ACTION: Michael to revisit his ednote in section 5 [recorded
    in [25]http://www.w3.org/2009/12/02-mediafrag-minutes.html#action03]
    [NEW] ACTION: Silvia to rework section 5 according to Raphael's
    restructuration plan
    c/0009.html due 2009-12-15 [recorded in
    [NEW] ACTION: Yves to come up with ABNF for header syntax [recorded
    in [28]http://www.w3.org/2009/12/02-mediafrag-minutes.html#action01]


    [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.eurecom.fr/~troncy/
Received on Wednesday, 2 December 2009 21:19:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:43 UTC