Media Fragments Working Group Teleconference

<trackbot> Date: 07 July 2010

<foolip> the bridge just keeps hanging up on me

<foolip> UK and France

<foolip> ok, that worked

1. Admin

Approved minutes of past telecon

http://www.w3.org/2010/06/23-mediafrag-minutes.html

http://www.w3.org/2010/06/30-mediafrag-minutes.html

+1

<dvdeurse> +1

minutes accepted

<foolip> +1

This will be last telecon for this summer

Next telecon will be 25/08

<scribe> scribe: raphael

<scribe> scribenick: raphael

2. Specification

Discussion about parsing name values pairs

Philip: name values pairs unknown should it be ignored ?
... and how we manage percent-decoding

<Yves> http://lists.w3.org/Archives/Public/public-media-fragment/2010Jul/0024.html

<Yves> axissegment = anysegment *( "&" anysegment )

Philip: my intention is to say that anysegment is timesegment, spacefragment, trackfragment, or unknown fragment

<Yves> http://www.example.com/foo.mov#foo=bar

Philip: but this does not work either since there is the problem of percent decoding
... I'm fine with http://www.example.com/foo.mov#foo=bar not be a media fragment

Yves: the issue is more if the t= is percent encoded
... I suggest to do this first step normalization step, doing at least percent-decoding of characters that are not delims, sub-delims, and other non-safe characters.

Philip: problem of the + sign in the timezone
... it seems to me very complex while what I propose seems simpler
... the spec is currently contradictory
... since the grammar says that arbitrary name value pairs is not valid

Raphael: how do you manage extensibility

Yves: do we really want extensibility?
... I'm not sure it is desirable

Silvia: her position "I personally believe they should be valid, since our discussion was

always that we would ignore name-value parameters that the UA (or the

server) doesn't understand.

scribe: the example was: http://www.example.com/football.movie#t=10,20&action=track

Yves: I'm not for being completely open to extensibility

Philip: you speculate a lot on what people could add after the # but should we really care about this ?

Raphael: I notice clearly a disagreement in the group currently

Yves's position is that for any unknow name values pair, the entire fragment sould be ignored

scribe: which is not clearly the position of Philip, and I think not what Silvia is thinking too

Davy: I understand Yves'as argument about I'm also concerned by the lack of forward compatibility

Philip: the current syntax is too strong on my opinion, so I don't want to have it normative

Yves: it is to be on the safe side for me to forbid unknown name value pairs

Raphael: other problem is %-decoding
... to we want to allow %-encode of t

Philip: yes, but then you're generic and don't need to treat track and id as special cases

<Yves> http://www.ietf.org/rfc/rfc3986.txt => 2.4. When to Encode or Decode

Yves: I suggest to add a paragraph in section 4.1
... explaining a normalization step

<Yves> %74=10,20

<Yves> normlziation phase => t=10,20

<Yves> track=foo%3dbar

<Yves> normalization phase => track=foo%3dbar

<Yves> track foo%3dbar

<Yves> foo=bar

Philip: I don't see the value of this pre-process step

Yves: we first need to extract the name value pairs
... before making the URI %-decoding step

Philip: we should first do parsing of arbitrary name value pairs
... and then process those name value pairs
... we then interpret the unicode syntax that results of the %-decoding of those pairs

<davy> +1 to Philip, this is also the way we parse fragments in our player

Yves: I agree that this is a way to do it ... but this will not be my way, I would implement it differently

close ACTION-182

<trackbot> ACTION-182 Include summary into wiki page closed

3. Save as Use Case

<foolip> raphael, I have to run for lunch, are we done discussing "my" issue?

yes foolip, until September where we will discuss the issue again

<foolip> ok, thanks all!

scribe: and before on the mailing list

Davy: I think we should save the whole media

Yves: save as the whole page ... would mean to save the html, the css, and the media _fragment_ (only the bytes downloaded)
... save as the media would mean save the entire media file

Chris question: Is it expected that for every URL request with a fragment that matches

the syntax of media fragments that the user agent will attempt to send

the Range header?

YES

I'm going through http://lists.w3.org/Archives/Public/public-media-fragment/2010Jun/0099.html

4. AOB

I will answer Chris