See also: IRC log
<trackbot> Date: 02 December 2009
<scribe> Scribe: Yves
<raphael> Minutes from last week: 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 -- OPEN
<trackbot> 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 ?
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 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: 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 http://lists.w3.org/Archives/Public/public-media-fragment/2009Sep/0099.html
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 http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions#Media_Fragment_Headers
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 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.
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
<raphael> See: 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 http://lists.w3.org/Archives/Public/public-media-fragment/2009Dec/0009.html due 2009-12-15 [recorded in http://www.w3.org/2009/12/02-mediafrag-minutes.html#action02]
<trackbot> Created ACTION-124 - Rework section 5 according to Raphael's restructuration plan http://lists.w3.org/Archives/Public/public-media-fragment/2009Dec/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 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> 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