- From: Raphaël Troncy <Raphael.Troncy@cwi.nl>
- Date: Wed, 02 Dec 2009 22:18:49 +0100
- 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
below.
Cheers.
Raphaël
-------------
[1]W3C
[1] http://www.w3.org/
Media Fragments Working Group Teleconference
02 Dec 2009
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-media-fragment/2009Dec/0003.html
See also: [3]IRC log
[3] http://www.w3.org/2009/12/02-mediafrag-irc
Attendees
Present
Raphael, Silvia, Yves, Philip_(irc), Michael
Regrets
Erik, Davy, Jack
Chair
Raphael
Scribe
Yves
Contents
* [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
[9] http://www.w3.org/2009/11/25-mediafrag-minutes.html
<raphael> +1 for accepting
no objection => accepted
<silvia> +1
Specification
<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 --
OPEN
<trackbot>
[10]http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/112
[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
cached?
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 ?
[11]http://lists.w3.org/Archives/Public/public-media-fragment/2009De
c/0008.html
[11]
http://lists.w3.org/Archives/Public/public-media-fragment/2009Dec/0008.html
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:
/2008/WebVideo/Fragments/media/fragf2f.mp4?t=12-21
<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
[12]http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spe
c/#naming-syntax
[12]
http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#naming-syntax
<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
me
<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
servers
<raphael> OK Philip, now I understand, indeed, we haven't specified
yet the syntax for 2) and 3)
<raphael> The only things we have:
[13]http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions#Me
dia_Fragment_Headers
[13]
http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions#Media_Fragment_Headers
<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
[14]http://lists.w3.org/Archives/Public/public-media-fragment/2009Se
p/0099.html
[14]
http://lists.w3.org/Archives/Public/public-media-fragment/2009Sep/0099.html
[15]http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-08
[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
[16]http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions#Me
dia_Fragment_Headers
[16]
http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions#Media_Fragment_Headers
[17]http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-08#sectio
n-5.4.2
[17]
http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-08#section-5.4.2
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
[18]http://www.w3.org/2009/12/02-mediafrag-minutes.html#action01]
<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
headers
will followup by email
Raphael: we need to update section 5
Silvia: happy to work on it
Rework of the section 5
<raphael> See:
[19]http://lists.w3.org/Archives/Public/public-media-fragment/2009De
c/0009.html
[19]
http://lists.w3.org/Archives/Public/public-media-fragment/2009Dec/0009.html
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
them?
Silvia: better if it is consistent
<scribe> ACTION: Silvia to rework section 5 according to Raphael's
restructuration plan
[20]http://lists.w3.org/Archives/Public/public-media-fragment/2009De
c/0009.html due 2009-12-15 [recorded in
[21]http://www.w3.org/2009/12/02-mediafrag-minutes.html#action02]
[20]
http://lists.w3.org/Archives/Public/public-media-fragment/2009Dec/0009.html
<trackbot> Created ACTION-124 - Rework section 5 according to
Raphael's restructuration plan
[22]http://lists.w3.org/Archives/Public/public-media-fragment/2009De
c/0009.html due 2009-12-15 [on Silvia Pfeiffer - due 2009-12-09].
[22]
http://lists.w3.org/Archives/Public/public-media-fragment/2009Dec/0009.html
<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
[23]http://www.w3.org/2009/12/02-mediafrag-minutes.html#action03]
<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
<trackbot>
[24]http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/119
[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
ADJOURNED
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
[26]http://lists.w3.org/Archives/Public/public-media-fragment/2009De
c/0009.html due 2009-12-15 [recorded in
[27]http://www.w3.org/2009/12/02-mediafrag-minutes.html#action02]
[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]
[26]
http://lists.w3.org/Archives/Public/public-media-fragment/2009Dec/0009.html
[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