IRC log of mediafrag on 2010-03-08

Timestamps are in UTC.

08:15:49 [RRSAgent]: RRSAgent has joined #mediafrag
08:15:49 [RRSAgent]: logging to http://www.w3.org/2010/03/08-mediafrag-irc
08:15:51 [trackbot]: RRSAgent, make logs public
08:15:51 [Zakim]: Zakim has joined #mediafrag
08:15:53 [trackbot]: Zakim, this will be IA_MFWG
08:15:53 [Zakim]: ok, trackbot, I see IA_MFWG(F2F)2:00AM already started
08:15:54 [trackbot]: Meeting: Media Fragments Working Group Teleconference
08:15:54 [trackbot]: Date: 08 March 2010
08:16:40 [raphael]: raphael has joined #mediafrag
08:16:47 [raphael]: trackbot, start telecon
08:16:49 [trackbot]: RRSAgent, make logs public
08:16:51 [trackbot]: Zakim, this will be IA_MFWG
08:16:51 [Zakim]: ok, trackbot, I see IA_MFWG(F2F)2:00AM already started
08:16:52 [trackbot]: Meeting: Media Fragments Working Group Teleconference
08:16:52 [trackbot]: Date: 08 March 2010
08:19:29 [raphael]: Topic: 1. Administrative
08:20:25 [raphael]: Present: Davy, Erik, Yves, Frank (observer), Jack, Raphael, Silvia (remote), Conrad (remote), Michael (remote), Philip (remote), Guillaume (remote)
08:20:43 [raphael]: Chair: Erik, Raphael
08:20:57 [raphael]: scribenick: raphael
08:21:22 [raphael]: Yves announced that W3C has a new CEO
08:21:33 [Yves]: s/Yves announced that W3C has a new CEO//
08:23:41 [erik]: http://www.w3.org/2008/WebVideo/Fragments/wiki/FifthF2FAgenda
08:23:44 [raphael]: Agenda: http://www.w3.org/2008/WebVideo/Fragments/wiki/FifthF2FAgenda
08:24:42 [raphael]: Raphael: Minor changes in the agenda
08:24:59 [raphael]: ... tomorrow, we switch the 2 sessions on implementation report and test cases
08:25:11 [raphael]: ... we will finish earlier, 15:30 PM most likely
08:29:08 [raphael]: Erik announced the nice dinner we will have, just to make jealous the remotes :-)
08:29:46 [silvia]: I'm having waffles and ice cream for dinner right now :)
08:30:33 [raphael]: OK, we will start, Conrad, Philip Michael, phone when you can, asap :-)
08:30:58 [raphael]: Topic: 2. Media Fragments syntax
08:31:29 [raphael]: First thing to consider: WG decision for expressing wall-clock time code
08:32:02 [Yves]: http://www.ietf.org/rfc/rfc3339.txt
08:32:17 [silvia]: I am fine with rfc3339
08:32:36 [raphael]: Yves: they all come from ISO
08:32:42 [silvia]: as reference
08:32:52 [raphael]: ... RFC3339 is just a recap, but defined with ABNF
08:34:09 [raphael]: RFC3339 abstract: "This document defines a date and time format for use in Internet
08:34:09 [raphael]: protocols that is a profile of the ISO 8601 standard for
08:34:09 [raphael]: representation of dates and times using the Gregorian calendar.
08:34:35 [conrad]: seems like a fine reference to me
08:34:54 [raphael]: Yves: there is no diff than with the ISO, except that it is defined with ABNF and we can copy directly the def
08:35:00 [Zakim]: +mhausenblas
08:37:04 [raphael]: Raphael: i remind you of the Resolution WG wiki page, http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions
08:38:30 [raphael]: Proposal: Use RFC3339 for expressing time and date format (same than ISO8601 but expressed in ABNF)
08:39:03 [jackjansen]: silvia, how about aaa?
08:39:27 [davy]: +1
08:39:40 [silvia]: +1
08:39:42 [erik]: +1
08:39:45 [jackjansen]: after femto comes atto, iirc...
08:39:47 [jackjansen]: +1
08:39:57 [raphael]: +1
08:40:24 [raphael]: RESOLUTION: we will express wall-clock time code with RFC3339
08:40:32 [RRSAgent]: I have made the request to generate http://www.w3.org/2010/03/08-mediafrag-minutes.html raphael
08:41:05 [conrad]: +1
08:43:37 [raphael]: Raphael: Yves is editing the spec _now_ so we save some actions :-)
08:43:50 [raphael]: ... the action is doing the changes in the spec
08:44:16 [silvia]: the aim is to have FPWD at the end of tomorrow, so editing will be highly necessary
08:44:16 [raphael]: Second thing to consider: WG decision: having quotes or not for name and id dimensions
08:44:42 [silvia]: can I point us to http://www.w3.org/2002/09/wbs/42785/MFRAGSYNTAXSEGMENT/results
08:45:00 [silvia]: ups
08:45:09 [silvia]: http://www.w3.org/2002/09/wbs/42785/MFRAGSYNTAXQUOTE/results
08:45:25 [silvia]: we had the discussion about quotes before
08:45:47 [raphael]: Yes, this is what Jack was remining us earlier
08:46:27 [raphael]: See also the 3rd point in http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions#Media_Fragment_URI_Syntax
08:46:36 [raphael]: "The WG resolved on 2009/01/28 that single quotes are optional to specify the value of the track and the name dimensions but that double quotes are forbidden (see also the poll results) "
08:48:15 [silvia]: I still stand to that decision
08:48:26 [silvia]: across all relevant dimensions
08:48:49 [raphael]: Raphael: relevant dimensions = track and id ?
08:49:14 [raphael]: Jack: if we don't use quotes, is there some strings we cannot specify ?
08:49:59 [raphael]: ... we thought there are some strings that require it, Philip states it is not necessary
08:50:19 [raphael]: ... I tried toget some counter examples, I found just one: YouTube, all the others work like Philip said
08:50:24 [foolip]: we use percent encoding, quotes don't help
08:50:50 [silvia]: Raphael: yes
08:51:12 [silvia]: I agree with foolip
08:51:26 [raphael]: ACTIOn-150?
08:51:26 [trackbot]: ACTION-150 -- Erik Mannens to summarize the discussion on the quotes in a mail or on the wiki -- due 2010-03-03 -- OPEN
08:51:26 [trackbot]: http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/150
08:51:50 [silvia]: but in the end, we cannot prohibit people from using them, so I would simply recommend against them in the spec
08:52:12 [raphael]: Are the single quotes helping? Apparently not, in this case, they have no value
08:52:43 [raphael]: To silvia, Davy didn't get any issues at all
08:52:56 [silvia]: using or not using quotes?
08:53:00 [foolip]: please don't make them optional, that way implementations are stilled forced to handle them
08:53:04 [jackjansen]: I agree: *if* quotes don't help we shouldn't use them.
08:53:40 [raphael]: To silvia: using it
08:54:09 [raphael]: Raphael: I agree with Philip and Jack, if they are not necessary, then we should NOT use them
08:54:17 [silvia]: so, Davy used quotes - did he use percent-encoding in his implementation? or were the quotes necessary because he didn't use percent-encoding?
08:55:27 [davy]: Silvia: indeed, we did not use percent-encoding because of the quotes
08:56:41 [raphael]: Raphael: so the question is between percent-encoding or single quotes?
08:57:42 [raphael]: Erik: I prepared a word document for my action-150, not online yet
08:58:00 [Zakim]: + +2712841aabb
08:58:15 [raphael]: zakim, aabb is Guillaume
08:58:15 [Zakim]: +Guillaume; got it
08:58:50 [silvia]: btw: 7.3. Back-End Transcoding in http://www.ietf.org/rfc/rfc3986.txt also talks about percent encoding in name-value pairs (here for query)
08:59:32 [raphael]: Erik listed 4 problems that will be list in the minutes
09:01:04 [erik]: Raphael raised possible problems on this issue on http://lists.w3.org/Archives/Public/public-media-fragment/2010Mar/0002.html
09:02:04 [foolip]: those aren't problems, those are limitations already listed in the spec
09:02:33 [raphael]: For the 3rd limitations, the "+" character, we should warn that the + should be %-encoded
09:02:35 [foolip]: by using quotes we would be adding a fith point
09:03:12 [foolip]: or are we not discussion percent-encoding vs quotes any longer?
09:04:13 [raphael]: Philip, yes, we are still discussing percent-encoding vs quotes
09:04:23 [raphael]: ... though the discussion is going in various ways
09:04:39 [guillaume]: examples?
09:05:46 [foolip]: + only needs to be percent-encoded if we make + be replaced by a space.
09:06:05 [Yves]: no, because of the duality of + used in the past to encode ' '
09:06:49 [raphael]: Raphael: we are back to the original point of discussion
09:06:53 [Yves]: '+' is a reserved character in rfc3986 (sub-delims)
09:07:37 [foolip]: I think that should be borne by those who use PHP and friends to parse MF, despite the problems
09:07:49 [raphael]: Jack: I would say, yes, take out the quotes, but perhaps put a note in the spec where we ask specifically some feedback on this issue
09:08:01 [foolip]: ok, so a URL with + unescaped is invalid?
09:08:54 [guillaume]: what are current and future best practice out there : less readable % encoded OR more structured quote based?
09:08:55 [raphael]: Jack: between quotes, the subdelim are still valid
09:09:13 [raphael]: Guillaume, read the long thread of dicussion we had :-)
09:09:59 [silvia]: + is a sub-delim according to http://www.ietf.org/rfc/rfc3986.txt and as such already needs to be %encoded
09:10:01 [Yves]: foolip: not invalid, but interop issues
09:10:40 [raphael]: Philip, can you phone in for 15 minutes ?
09:10:56 [foolip]: raphael: can I use Skype?
09:11:03 [foolip]: I have no real phone
09:11:19 [silvia]: it really isn't a problem - it's what the server makes of it that counts - and YouTube accepts + in lieu of ' ', but that doesn't mean others do
09:11:27 [raphael]: Yes PHilip
09:11:52 [raphael]: zakim, code?
09:11:52 [Zakim]: the conference code is 3724 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), raphael
09:13:45 [raphael]: Raphael: to Philip, Silvia, we are resuming the discussion, having single quotes or not. Single quotes have sometime values in the sense that some track names will not be %-encoded
09:15:01 [silvia]: the spec says that you have to %encode the content values
09:16:09 [raphael]: Jack: if I read the RFC 3986, section 7.2, it says that sub-delim MUST be %-encoded if you want them to be treated as data
09:16:26 [Yves]: silvia; yes, that is right, encode values
09:17:29 [raphael]: Erik: is that the case also for the ' ' (space) ?
09:18:42 [raphael]: ... so why you would like to put quotes, if the browser doesn't transform the space into %20 ?
09:21:59 [silvia]: well, space is not part of the delimiters, but section 2.1 explicitly talks about %20
09:22:16 [raphael]: Philip: any special character which is not part of the reserved set is transformed into a %-encoding version
09:22:26 [raphael]: Raphael: this is what you said Philip?
09:22:32 [foolip]: yes
09:22:40 [raphael]: ... transformed by the browsr
09:22:47 [raphael]: s/browsr/browser
09:22:48 [foolip]: with the addition that I haven't tested all possible input
09:24:35 [silvia]: unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
09:24:57 [raphael]: Jack summary: we have 3 sets of characters
09:25:25 [silvia]: "The only exception is for
09:25:25 [silvia]: percent-encoded octets corresponding to characters in the unreserved
09:25:25 [silvia]: set, which can be decoded at any time."
09:25:28 [raphael]: ... unreserved: there are never been encoded (if you do it, you type too much)
09:25:35 [silvia]: so, everything that is not in the unreserved set has to be encoded
09:25:47 [raphael]: ... reserved: delim and sub delim, MUST be %-encoded
09:25:51 [silvia]: according to http://www.ietf.org/rfc/rfc3986.txt
09:26:44 [raphael]: ... the rest ... which is just illegal (including the space)
09:27:02 [silvia]: or better still, in 2.5:
09:27:07 [silvia]: "When a new URI scheme defines a component that represents textual
09:27:07 [silvia]: data consisting of characters from the Universal Character Set [UCS],
09:27:07 [silvia]: the data should first be encoded as octets according to the UTF-8
09:27:07 [silvia]: character encoding [STD63]; then only those octets that do not
09:27:07 [silvia]: correspond to characters in the unreserved set should be percent-
09:27:08 [silvia]: encoded."
09:28:19 [raphael]: Raphael: I think I'm convinced that the quotes are therefore useless
09:29:00 [silvia]: I am too :)
09:29:05 [raphael]: Jack is too
09:29:17 [jackjansen]: Whatever you say, Chairman
09:30:41 [raphael]: Proposa: the WG does NOT consider that single quote is a special character. It will not be used by the Media Fragment syntax. It contradicts a earlier resolution from the group, but the group acquired a better knowledge of the role of the quotes in a URI since.
09:30:54 [raphael]: s/Proposa/Proposal
09:31:13 [silvia]: +1
09:31:17 [foolip]: +1
09:31:19 [jackjansen]: +1
09:31:20 [davy]: +1
09:31:22 [raphael]: +1
09:31:22 [mhausenblas]: +1
09:31:22 [Yves]: =
09:31:26 [erik]: +1
09:31:31 [jackjansen]: ?
09:31:37 [Yves]
09:31:41 [guillaume]: ?
09:32:09 [jackjansen]: Or should we vote %2b1?
09:32:37 [guillaume]: %2b1 then
09:33:05 [raphael]: RESOLUTION: the media fragment syntax does not treat the single quote as a special character. Values for the track and id dimensions should be percent-encoded when necessary
09:33:23 [jackjansen]: 3b2 otoh is an old unix machine...
09:35:12 [foolip]: note that even the names can be percent encoded, even if it's ugly
09:35:17 [raphael]: Jack: we should clarify and put a strong statement in the spec that the number of characters we can use non-%-encoded is very limited and point to them the RFC3339 for that. Most of the characters should be %-encoded
09:35:44 [foolip]: I mean in t=1, t could be percent-encoded
09:35:52 [raphael]: Yes Philip, but for the unreserve characters, you're typing too much by escapting them
09:35:53 [foolip]: unless we want to decide otherwise
09:36:11 [raphael]: s/unreserve/unreserved
09:36:17 [foolip]: fine, as long as we agree it's valid
09:36:49 [silvia]: t is in the unreserved set and thus rfc3986 recommends not encoding it
09:37:08 [fdenoual]: Point to RFC 3986 instead of RFC3339 in the above clarification
09:37:52 [raphael]: s/RFC3339/RFC3986
09:38:51 [raphael]: Raphael: Silvia, yes, but it also says that it does not matter if you encode it
09:38:58 [silvia]: 6.2.2.2. Percent-Encoding Normalization <- explicitly talks about not encoding them
09:39:04 [silvia]: yes, I agree
09:39:16 [raphael]: s/the RFC3339/the RFC3986
09:40:01 [erik]: rrsagent, draft minutes
09:40:01 [RRSAgent]: I have made the request to generate http://www.w3.org/2010/03/08-mediafrag-minutes.html erik
09:41:31 [raphael]: Raphael: two remaining problems
09:42:25 [raphael]: ... a) We should put somewhere in the spec a warning to the reader that most of the characters will be escaped, since the unreserved set of characters that do not need %-encoding is very limited
09:42:46 [raphael]: ... b) Should we keep the section 5.1.1 like that? (http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-name-value-components)
09:42:51 [raphael]: Jack: I'm very against
09:42:56 [raphael]: Yves: I'm very agains too
09:43:12 [silvia]: against which?
09:43:40 [fdenoual]: Section 5.1.1
09:43:46 [jackjansen]: Against using pseudo-code fragements in normative text, as in 5.1.1
09:44:02 [silvia]: I do not think we need to repeat what rfc3986 says about percent-encoding, so I am against a)
09:44:28 [foolip]: a) seems redundant
09:44:50 [mhausenblas]: Michael: I gotta drop out now for an hour or so - will join you likely after the lunch break (hope I can make it earlier)
09:44:51 [silvia]: b) otoh clarifies a lot - I don't mind the pseudo-code
09:44:54 [silvia]: why are you against it?
09:45:12 [Zakim]: -mhausenblas
09:46:00 [silvia]: it clarifies what rfc3986 doesn't specify, but refers to a lot: what are name-value pairs in queries (and for us in fragments)
09:47:00 [foolip]: if someone can define processing of name-value pairs by some other method, fine
09:48:10 [foolip]: but I'm definitely against removing normative text without replacing it or leaving it "implicit" (i.e. undefined)
09:48:32 [raphael]: OK, back to a), we don't want to repeat but add some examples to clarify
09:48:55 [raphael]: Yves is editing live the spec, to remove the production rules with the quotes
09:49:15 [raphael]: ... and add some examples in section 4.2.5
09:49:39 [raphael]: ... examples of a temporal fragment with a + that is encoded, a track fragment with a '&' that is encoded, etc.
09:49:53 [silvia]: zakim, code?
09:49:53 [Zakim]: the conference code is 3724 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), silvia
09:50:20 [raphael]: ... the idea is to warn once more the reader that most of the chacacters need to be encoded, it seems useful since we had some much dicussion about it
09:50:29 [raphael]: now: b)
09:50:57 [raphael]: Jack: I have written an email why I think the pseudo-code is not good in the spec
09:51:28 [Zakim]: + +28012aacc
09:51:36 [silvia]: zakim, aacc is me
09:51:36 [Zakim]: +silvia; got it
09:53:23 [silvia]: section 4.2.3 has quotes in examles
09:54:05 [silvia]: and 4.2.4
09:55:43 [raphael]: Raphael: there is a problem with the section 5.1.1
09:56:05 [raphael]: Jack: the pseudo code is fuzzy, less valuable than written in a declarative language
09:56:17 [raphael]: ... the pseudo code will always make things less clear
09:58:43 [silvia]: mediasegment = namesegment / axissegment
09:58:44 [silvia]: axissegment = ( http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#timesegment / http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#spacesegment / http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#tracksegment )
09:58:44 [silvia]: *( "&" ( http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#timesegment / http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#spacesegment / http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#tracksegment )
09:58:53 [raphael]: Jack: I propose to replace this pseudo algorithm with just a few sentences that state we must first identify the key and values
09:59:02 [raphael]: ... follow what RFC is saying
09:59:36 [raphael]: Silvia: there are things you cannot write in ABNF
09:59:50 [raphael]: ... I prefer the text that Philip wrote
10:03:25 [raphael]: Raphael: the non agreement seems to be between specifying things in a declarative language vs procedural language
10:05:38 [raphael]: Silvia: you can rephrase this section, but I think we should NOT remove it
10:07:09 [foolip]: I would like to speak
10:07:32 [erik]: erik has joined #mediafrag
10:08:00 [raphael]: Yes, Philip, 2 sec
10:08:24 [silvia]: zakim, mute me
10:08:24 [Zakim]: silvia should now be muted
10:11:11 [Yves]: adding examples would be good
10:11:25 [Yves]: always helpful to clarify things for both programmers and users
10:12:33 [Zakim]: -silvia
10:13:08 [Yves]: say "as transcribed in pseudo-code" instead of "as an example"
10:13:29 [Zakim]: +silvia
10:13:32 [silvia]: zakim, mute me
10:13:32 [Zakim]: silvia should now be muted
10:13:41 [raphael]: Yves: I propose to write the ABNF declarative language, and then, "as transcribed in pseudo code" and put the text of Philip^
10:13:54 [foolip]: this is the only place that defines how to split name-value pairs, it is not clarifying
10:14:08 [raphael]: the spec can be restructured
10:14:24 [foolip]: you'll notice that there's no ABNF for &-=-separated lists
10:14:41 [silvia]: I wouldn't move it to another location - it's in the right place
10:14:47 [jackjansen]: Philip, splitting name/vsalue parise is described in the abnf...
10:14:52 [jackjansen]: s/parise/pairs
10:15:26 [erik]: s/vsalue/value
10:15:27 [raphael]: See http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#fragment-structure
10:15:29 [jackjansen]: Yep, very first 2 productions
10:15:35 [Yves]: axissegment = ( timesegment / spacesegment / tracksegment )
10:15:35 [Yves]: *( "&" ( timesegment / spacesegment / tracksegment )
10:15:41 [foolip]: I removed that, someone put it back it seems
10:15:47 [raphael]: :-)
10:15:54 [foolip]: it doesn't make any sense to have both
10:16:14 [silvia]: I think it does, because that rule is rather unclear
10:16:18 [raphael]: OK, we make a smoking coffee break
10:16:28 [raphael]: we come back after
10:16:31 [jackjansen]: silvia, which rule is unclear, and why?
10:16:31 [raphael]: 15 minutes break
10:16:41 [guillaume]: ok
10:16:58 [silvia]: the rule in 4.1 is missing the percent-encoding
10:17:20 [Yves]: no, it's included in utf8string definition
10:17:30 [foolip]: the axissegment makes no sense, timesegment and others should be matched *after* percent-decoding
10:18:26 [raphael]: We do the break ... and I will phrase after my proposal of restructuring ... just wait
10:18:30 [foolip]: unless we have ABNF for percent-encoding + UTF-8 then there cannot be a complete ABNF at the URI level
10:18:44 [foolip]: there are two levels
10:19:02 [silvia]: and the way it is now, the dimension value is not %encoded
10:19:33 [RRSAgent]: I have made the request to generate http://www.w3.org/2010/03/08-mediafrag-minutes.html raphael
10:19:36 [silvia]: ok, I'll be back in 15
10:19:37 [foolip]: yes, I removed the parts that didn't make sense, now that they are back the spec is just nonsense
10:19:40 [jackjansen]: Philip, that's about which terminals you have. Parsing vs. Lexing.
10:19:44 [Zakim]: -silvia
10:20:22 [raphael]: close ACTION-150
10:20:22 [trackbot]: ACTION-150 Summarize the discussion on the quotes in a mail or on the wiki closed
10:20:34 [raphael]: close ACTION-143
10:20:34 [trackbot]: ACTION-143 Move 5.1.5 into a new section closed
10:21:07 [raphael]: close ACTION-144
10:21:07 [trackbot]: ACTION-144 Move the section 5.1.1 to the top closed
10:21:11 [foolip]: jackjansen: ? What does that mean, in practice?
10:22:01 [RRSAgent]: I have made the request to generate http://www.w3.org/2010/03/08-mediafrag-minutes.html raphael
10:23:39 [Zakim]: - +0329331aaaa
10:23:53 [Zakim]: -Guillaume
10:23:54 [Zakim]: IA_MFWG(F2F)2:00AM has ended
10:23:55 [Zakim]: Attendees were +0329331aaaa, mhausenblas, +2712841aabb, Guillaume, +28012aacc, silvia
10:24:17 [jackjansen]: ok, time to go home, zakim seems to think... :-)
10:25:16 [Zakim]: IA_MFWG(F2F)2:00AM has now started
10:25:23 [Zakim]: + +0329331aaaa
10:27:21 [silvia]: Yves: TCP/IP is not specified in declarative syntax, but has plenty of procedural sections in it, http://www.ietf.org/rfc/rfc793.txt
10:27:32 [silvia]: e.g.
10:27:33 [silvia]: SYN-RECEIVED STATE
10:27:33 [silvia]: If SND.UNA =< SEG.ACK =< SND.NXT then enter ESTABLISHED state
10:27:33 [silvia]: and continue processing.
10:27:35 [silvia]: If the segment acknowledgment is not acceptable, form a
10:27:37 [silvia]: reset segment,
10:27:41 [silvia]: <SEQ=SEG.ACK><CTL=RST>
10:27:45 [silvia]: and send it.
10:31:12 [Yves]: silvia, as I said earlier, I am ok to have both
10:32:10 [foolip]: it's kind of pointless to have this discussion without an alternative available for evaluation
10:33:17 [foolip]: the most important thing is that it is actually defined how to process name-value pairs
10:35:09 [silvia]: Yves, I was just curious about your statement and investigated :)
10:35:23 [silvia]: I agree, I think we should have both
10:35:40 [foolip]: the ABNF doesn't, but by having it the spec is simply self-contradictory about how to handle invalid name/value pairs
10:35:41 [silvia]: it will just be a challenge to make sure they actually express the same and don't contradict each other
10:36:00 [foolip]: I'd prefer to just have one representation, for sanity
10:36:24 [foolip]: the two current ones don't express the same thing, at all
10:36:35 [silvia]: so we need to fix that
10:36:41 [foolip]: indeed
10:36:52 [raphael]: Topic: 3. Structure of the spec
10:38:39 [raphael]: Raphael: from a high level view, I think we have various bits wrongly placed
10:38:50 [raphael]: ... Section 4 is about Media Fragment URI syntax
10:39:14 [raphael]: ... but Section 5 is about both how to process this syntax and how the protocol is working, soon with the headers syntax
10:39:51 [raphael]: ... I suggest that everything about the URI syntax should go in Section 4, so also the bits in 5.1.1 and 5.1.2
10:40:07 [raphael]: ... and the section 5 should be only about protocol and headers syntax
10:41:14 [raphael]: ... and I have also problems with the section 5.1.3
10:43:04 [silvia]: that refers only to section 5.1 ?
10:43:27 [raphael]: ... if the section 5.1.3 is mainly about how to render a fragment in the UA, perhaps put a section 5.4 for that
10:43:29 [silvia]: I agree, 5.1.3 is a bit of a headache
10:43:49 [raphael]: what do you mean: "that refers only to section 5.1 ?" ?
10:44:02 [silvia]: I think the last paragraph in 5.1.3 needs its own section, but the rest doesn't
10:44:36 [silvia]: when I said "that refers only to section 5.1" I meant: your problems with syntax in section 5 are actually only with section 5.1, right?
10:44:58 [raphael]: Yves: following Frank suggestion, I would suggest having 4. Syntax; 5. Protocol; 6. Display
10:45:12 [raphael]: Raphael: not only silvia but mainly with 5.1
10:45:36 [silvia]: I don't see any new syntax anywhere else
10:45:38 [foolip]: no processing?
10:46:02 [silvia]: and move 6. Error handling to 7 ?
10:46:07 [raphael]: Raphael: Philip, 5. Protocol means processing the fragments and generate the headers
10:46:10 [raphael]: yes silvia
10:46:27 [foolip]: please no error handling :(
10:46:29 [raphael]: Silvia, new syntax elements soon to be introduced with ABNF versions of HTTP headers and HTTP responses
10:46:35 [foolip]: it's just "handling"
10:46:38 [raphael]: Why Philip ?
10:46:44 [foolip]: you handle errors and non-errors in the same way
10:46:59 [silvia]: those should stay with the protocol
10:47:01 [foolip]: it's much clearer to put it in the same section
10:47:22 [raphael]: I don't understand silvia, what should stay with the protocol?
10:47:30 [silvia]: they are, but finding a better name for the section is difficult - got a proposal?
10:47:48 [jackjansen]: silvia, how about "implementation guidelines"?
10:47:49 [silvia]: the syntax specification of the HTTP headers need to say with the protocol
10:47:57 [raphael]: Philip: you want to have the errors in the same section than the protocol?
10:48:08 [raphael]: this is what I said Silvia
10:48:08 [foolip]: not guidelines, normative, absolute rules
10:48:23 [raphael]: status of section (normative vs not) is independent
10:48:34 [silvia]: it's not actually about implementation guidelines - it's about how to process actual values
10:48:44 [silvia]: maybe it's the processing section that Philip is missing
10:48:51 [raphael]: can you phone in Silvia ... too many misunderstandings
10:49:48 [silvia]: raphael: good - just wanted to make sure case it's syntax, too :)
10:50:05 [silvia]: just two different communication threads :)
10:50:23 [foolip]: no no no
10:50:38 [foolip]: I would like to speak :)
10:50:46 [silvia]: zakim, code?
10:50:46 [Zakim]: the conference code is 3724 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), silvia
10:52:06 [foolip]: raphael: no, there's no phone around
10:52:11 [Zakim]: +silvia
10:52:17 [silvia]: zakim, mute me
10:52:17 [Zakim]: silvia should now be muted
10:54:22 [silvia]: zakim, unmute me
10:54:22 [Zakim]: silvia should no longer be muted
10:55:11 [foolip]: ok, I'll just write on IRC
10:57:59 [raphael]: Raphael: my proposal is section 4 = media fragment URI syntax (including the current sections 5.1.1 and 5.1.2)
10:58:38 [raphael]: ... section 5 = protocol handling, ABNF syntax of the HTTP headers, communication between servers and UA (current sections 5.2 and 5.3)
10:58:56 [raphael]: ... section 6 = display (current section 5.1.3)
10:59:06 [foolip]: I like semantics
10:59:07 [raphael]: ... section 7 = semantics + error handdling
10:59:19 [foolip]: I'd like to explain the different levels here
10:59:50 [foolip]: lowest level: URI fragment component (or URI query component)
10:59:57 [raphael]: Jack propose to switch sections 6 and 7
11:00:15 [raphael]: ... semantics first, then display / render
11:00:21 [foolip]: the syntax of this is *arbitrary* &-=-separated strings
11:00:22 [silvia]: I agree
11:00:47 [foolip]: the result of parsing this is a list of name-values
11:00:59 [foolip]: media fragments is modelled on top of this, not on the URI string
11:01:05 [foolip]: in my versions
11:01:17 [jackjansen]: fuly agree with philip
11:01:21 [jackjansen]: fully
11:01:24 [foolip]: so, the ABNF or whatever must reflect this
11:02:05 [foolip]: we can't say that the fragment component is composed from timesegment or whatever
11:02:20 [raphael]: Raphael: we all agree with you Philip, and suggest to add this in Section 4
11:02:32 [foolip]: i.e. the ABNF in 4.1 must be changed, or removed
11:02:56 [silvia]: zakim, mute me
11:02:56 [Zakim]: silvia should now be muted
11:03:00 [jackjansen]: Philip, why?
11:03:06 [raphael]: Philip: we don't understand this: " we can't say that the fragment component is composed from timesegment or whatever"
11:03:33 [foolip]: jackjansen: because timeprefix and timeparam should be matched after splitting
11:03:40 [foolip]: and after percent-decoding and UTF8-decoding
11:03:56 [foolip]: i.e. they aren't on the same "level"
11:04:01 [jackjansen]: That's because urls are our main language.
11:04:16 [jackjansen]: if c++ was our main language it would be datastructures.
11:04:34 [foolip]: the current *segment syntaxes don't make this distinction
11:05:03 [jackjansen]: No, because it's semantics, not syntax.
11:05:23 [jackjansen]: Same would be true for c++ datastructure declarations...
11:06:10 [Yves]: are you missing the "timeprefix = timeparam" in 4.1 ?
11:07:09 [Yves]: (and same for all other examples, saying that it's foo = bar)
11:07:49 [silvia]: I think the difference comes from the fact that Philip is looking at the URL from a parsing POV and Yves from a production POV
11:08:04 [Yves]: the grammar says that it's foo = bar then bar is percent encoded (see def of utf8string)
11:08:18 [Yves]: so the grammar already says that you split, then decode
11:08:27 [fdenoual]: Is is possible to express sthg like: segment = *(segmentname=segmentvalue) ?...
11:08:38 [fdenoual]: ... and then express segmentname and segmentvalue
11:09:27 [silvia]: I think the difference is that we need to keep the option open to have other name-value pairs in the URL, too
11:09:39 [silvia]: we cannot just restrict it to the ones we define
11:10:29 [conrad]: conrad has joined #mediafrag
11:14:47 [raphael]: Jack: if I understand Philip correctly, the structuring of the ABNF is not the one that implementers will follow, and that will hinder future extensibility
11:14:54 [raphael]: is that correct?
11:15:06 [foolip]: yes
11:15:41 [foolip]: so jackjansen is suggesting that implementors should ignore the spec and accept other input than the ABNF allows?
11:15:51 [raphael]: no
11:15:58 [fdenoual]: I think Philip would like to see translated "fragment identifier consists of a list of name/value pairs" into ABNF at top-level.
11:16:36 [foolip]: there should be no spirit, just hard, unambiguous requirements
11:16:55 [foolip]: we should specify exactly what UAs should accept
11:17:08 [foolip]: otherwise we won't have interop
11:17:12 [jackjansen]: Philip, we cannot have requirements for extensions.
11:17:20 [foolip]: I can hear
11:17:24 [foolip]: just not talk
11:17:30 [foolip]: ok
11:18:04 [silvia]: there is no requirement for extensions, but we have to specify the document so we allow them
11:18:11 [foolip]: we can be very sure that we want to add things like foo=bar, no?
11:18:33 [silvia]: indeed, we need to have the spec written such that any name-value pair is parsed
11:18:35 [foolip]: because the syntax doesn't allow it
11:18:49 [silvia]: and only the ones that are relevant to us will be specified in the document
11:19:11 [foolip]: unless we want implementors to guess what we meant
11:19:18 [silvia]: right now the ABNF spec doesn't allow other name-value pairs
11:19:31 [foolip]: yes, jackjansen is on the right track
11:19:56 [silvia]: I agree :)
11:20:13 [silvia]: it's what the pseudocode describes, but not the ABNF right now
11:20:25 [raphael]: ok, we start to understand *ad* agree
11:20:40 [raphael]: changes need to be made in Section 4
11:20:48 [raphael]: I would suggest to make these changes during lunch break
11:21:08 [foolip]: yes, what jackjansen is saying is exactly what I intended when making the processing section for name-value strings
11:21:09 [silvia]: and the %encoding / decoding needs to happen in the URI part, not in the name-value spec part
11:21:54 [raphael]: and we are all enthousiastic, thanks Philip
11:22:05 [silvia]: excellent :))
11:22:16 [foolip]: indeed, it's important that implementations aren't required to understand all current and future possible syntax :)
11:23:12 [foolip]: thanks, I will drop out now to have dinner
11:23:29 [foolip]: I haven't been that involved with multiple tracks anyway
11:24:40 [silvia]: zakim, unmute me
11:24:40 [Zakim]: silvia should no longer be muted
11:25:20 [raphael]: Conlusion: Yves will work at the beginning of the morning on the reshuffle of the section 4
11:25:21 [raphael]: Topic: 4. Multiple tracks
11:26:49 [raphael]: Can we have multiple tracks at all?
11:28:20 [raphael]: Jack: we said that multiple ids or multiple parallel tracks is too complicated
11:28:28 [fdenoual]: ABNF definition of axissegment enables combination of tracks
11:29:51 [silvia]: zakim, mute me
11:29:51 [Zakim]: silvia should now be muted
11:30:30 [raphael]: Silvia: we talked about multiple occurrence of t=x, and I agree this is an error
11:30:49 [raphael]: ... we haven't dicussed this for tracks
11:31:08 [raphael]: Jack: exception for tracks?
11:31:41 [silvia]: there should only be one track dimension in a URL, but it can have a semicolon separated list of tracks
11:31:52 [raphael]: Yes, this is what Jack said
11:32:20 [raphael]: Raphael: should we have a resolution for that? and check afterwards, we can actually generate good headers with that :-)
11:32:35 [silvia]: ; is a sub-delimiter in URI, so we can use it
11:33:19 [raphael]: Jack: yes, but we need to make sure that at the semantics level, t=10,20;30,40 is incorrect
11:34:06 [silvia]: it's already syntactically incorrect
11:34:44 [silvia]: with multiple tracks we are only changing the production rule of the value of the track segment
11:34:51 [silvia]: not all values of all segments
11:34:56 [jackjansen]: So assume track=audio;subtitle is correct. Now how about id=section1;section2 ?
11:35:15 [silvia]: 4.2.3
11:35:58 [silvia]: tracksegment = trackprefix "=" trackparam
11:35:58 [silvia]: trackprefix = %x74.72.61.63.6B ; "track"
11:35:58 [silvia]: trackparam = utf8string
11:36:03 [silvia]: change to
11:36:06 [raphael]: Yes, silvia, that is easy
11:36:19 [silvia]: tracksegment = trackprefix "=" trackparam [; trackparam]*
11:36:26 [silvia]: or something similar :)
11:37:38 [raphael]: This is what Yves was writing on the board
11:37:54 [raphael]: ... changes will happen during your sleep
11:39:41 [raphael]: Proposal: the media fragment URI will allow multiple values for the track dimension, separated by a semi-colomn
11:39:57 [raphael]: s/colomn/colon
11:40:33 [jackjansen]: +1
11:40:34 [Yves]: =
11:40:34 [davy]: +1
11:40:35 [erik]: +1;
11:40:55 [silvia]: +1
11:41:02 [raphael]: RESOLUTION: the media fragment URI will allow multiple values for the track dimension, separated by a semi-colon, assuming we are considering only one temporal range
11:41:12 [RRSAgent]: I have made the request to generate http://www.w3.org/2010/03/08-mediafrag-minutes.html raphael
11:42:02 [silvia]: the semantics are an enumeration of the chosen tracks, right?
11:42:10 [jackjansen]: corect
11:42:47 [raphael]: Topic: 5. Multiple but equivalent Content-Range headers
11:43:00 [silvia]: zakim, unmute me
11:43:00 [Zakim]: silvia should no longer be muted
11:43:06 [raphael]: Silvia: I'm happy to have a new header called Content-Equivalent
11:43:24 [raphael]: s/Content-Equivalent/Range-Equivalent
11:43:43 [Yves]: s/Range-Equivalent/Content-Range-Equivalent
11:44:43 [silvia]: 5.2.2
11:45:07 [raphael]: Silvia: reading the editorial note at the end of the section 5.2.2
11:45:31 [raphael]: ... Conrad used to named it Fragment, and we call it Content-Range-Equivalent
11:45:53 [raphael]: ... the purpose is to do the mapping between equivalent ranges expressed in different units
11:45:58 [Yves]: if we need to enumerate tracks, we may need to quote them to isolate possible occurences of the delimiter...
11:46:04 [raphael]: ... e.g. between seconds and bytes
11:47:49 [Zakim]: -silvia
11:48:29 [silvia]: zakim, code?
11:48:29 [Zakim]: the conference code is 3724 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), silvia
11:49:15 [Zakim]: +silvia
11:50:30 [raphael]: Raphael: ok, we will work on the ABNF syntax of the headers this afternoon
11:51:05 [raphael]: Yves: in the headers, if there are multiple tracks, we might need quotes
11:51:08 [raphael]: ... I need to check
11:53:45 [Yves]: http://tools.ietf.org/html/rfc2047
11:54:57 [silvia]: zakim, mute me
11:54:57 [Zakim]: silvia should now be muted
11:56:13 [silvia]: zakim, unmute me
11:56:13 [Zakim]: silvia should no longer be muted
11:56:14 [raphael]: Jack: ok, then i suggest to use this rfc also
11:56:17 [jackjansen]: Silvia, could you follow that?
11:57:45 [raphael]: Not really Silvia, look at RFC 2047, section 4.2
12:00:05 [raphael]: Jack: are you not mixing queries and fragments? queries are percent-encoded
12:02:52 [conrad]: to me, the header name "Content-Range-Equivalent" seems to imply a contiguous subrange of the resource, whereas a selection (intersection) of tracks is something more complex
12:03:08 [Yves]: foo=bar
12:03:21 [Yves]: in the uri: foo=b%XXr
12:03:28 [Yves]: in the header:
12:03:36 [Yves]: Toto: foo=bar
12:03:42 [Yves]: or
12:04:10 [foolip]: "syntax of name-value pairs", independent of anything else in the spec
12:04:12 [silvia]: Toto: foo=b%XXr
12:04:23 [Yves]: foolip, yes
12:04:47 [Yves]: URI parsing => name=value pairs => encode in HTTP
12:05:15 [foolip]: I'd put a step between name-value pairs and HTTP
12:05:18 [raphael]: Raphael: I think we should have this in a diagram, re: URI parsing => name=value pairs => encode in HTTP
12:05:41 [foolip]: which is interpreting the list of name-value pairs that resulted from the first step
12:05:51 [Yves]: URI parsing (percent decoding) => name=value pairs => (rfc2047encoding) HTTP
12:05:54 [Zakim]: +??P2
12:06:04 [conrad]: Zakim, ??P2 is me
12:06:04 [Zakim]: +conrad; got it
12:06:19 [raphael]: Silvia: I wonder why the percent decoding should happen at all on client side
12:06:28 [conrad]: Zakim, mute me
12:06:28 [Zakim]: conrad should now be muted
12:06:47 [raphael]: Silvia: ... but perhaps clients are already doing that already
12:06:54 [Yves]: http://www.example.com/foo#t=%34
12:07:19 [Yves]: a client must decode that
12:07:54 [raphael]: Jack: if my URL is file:// the client is the only one who can decode
12:08:34 [conrad]: Zakim, unmute me
12:08:34 [Zakim]: conrad should no longer be muted
12:09:09 [Zakim]: -silvia
12:09:39 [conrad]: Zakim, mute me
12:09:39 [Zakim]: conrad should now be muted
12:10:51 [conrad]: Zakim, unmute me
12:10:51 [Zakim]: conrad should no longer be muted
12:11:19 [Zakim]: - +0329331aaaa
12:11:23 [RRSAgent]: I have made the request to generate http://www.w3.org/2010/03/08-mediafrag-minutes.html raphael
12:11:26 [Zakim]: -conrad
12:11:27 [Zakim]: IA_MFWG(F2F)2:00AM has ended
12:11:28 [Zakim]: Attendees were +0329331aaaa, silvia, conrad
12:12:46 [raphael]: Silvia: OK, I understand the argument, and I agree that clients might also decode the fragment part of the url
12:13:18 [raphael]: Raphael: I would propose that somewhere in the document we have a figure that represents the following steps: URI parsing (percent decoding) => name=value pairs => (rfc2047encoding) HTTP
12:13:21 [RRSAgent]: I have made the request to generate http://www.w3.org/2010/03/08-mediafrag-minutes.html raphael
12:14:04 [silvia]: should be the new first part of section 4, which has the general uri media fragment parsing in it
12:28:29 [foolip]: ok, I will have to leave now too, it's way after work hours
12:31:16 [raphael]: thanks philip
12:31:34 [raphael]: we will make a summary tonight ... talk to you tomorrow morning
12:31:52 [raphael]: it would be great if you would be able to phone for limited period of time when necessary
12:32:21 [raphael]: do you know you can open a skype out account and phone on copper line ? it's very cheap
12:32:39 [raphael]: there is also free voip service ... like one hour free phone per day
12:32:46 [raphael]: voipbuster I think does that
12:38:06 [foolip]: I've had a look at it, I'll try to arrange something
12:38:44 [raphael]: Topic: 6. HTTP headers syntax
12:38:52 [raphael]: close ACTION-141
12:38:52 [trackbot]: ACTION-141 Add a paragraph in the section 5.2.1 that further clarify the role of the UA for rendering a media fragment closed
12:39:17 [raphael]: ACTION-132?
12:39:17 [trackbot]: ACTION-132 -- Philip Jägenstedt to send to the mailing list a description of a new issue to be discussed (dealing with decimal for specifying time?) -- due 2010-02-03 -- OPEN
12:39:17 [trackbot]: http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/132
12:39:26 [raphael]: Philip, do you remember this action?
12:40:40 [foolip]: no, was that something spawned in another teleconf?
12:41:13 [foolip]: in any case it had to do with the NPT syntax and I did send such a mail and it has since been changed
12:41:25 [foolip]: so close the action as done and all is good
12:45:03 [raphael]: ok
12:46:13 [raphael]: Philip, when the action was given: http://www.w3.org/2010/01/27-mediafrag-minutes.html#item04
12:46:34 [raphael]: are you sure we can close it?
12:48:22 [foolip]: yes, the current format allows a decimal point with no trailing digits
12:52:44 [raphael]: close ACTION-132
12:52:44 [trackbot]: ACTION-132 Send to the mailing list a description of a new issue to be discussed (dealing with decimal for specifying time?) closed
12:57:44 [silvia]: silvia has joined #mediafrag
13:04:09 [raphael]: Raphael: ok, we resume, I suggest we work on the ABNF syntax of the HTTP headers for the time, space and track dimensions this afternoon
13:04:17 [raphael]: ... we will work on board
13:04:28 [raphael]: Conrad, Philip or Michael, do you plan to phone in ?
13:19:10 [conrad]: ok, ie. in 11min time?
13:23:42 [Yves]: http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-09#section-5.4.1
13:37:13 [Zakim]: IA_MFWG(F2F)2:00AM has now started
13:37:20 [Zakim]: + +0329331aaaa
13:37:58 [raphael]: zakim, aaaa is WG_room
13:37:58 [Zakim]: +WG_room; got it
13:38:27 [raphael]: Reading all http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/, new version 1.62
13:38:45 [raphael]: Jack: as a user, I'm now interested in sections 4 and 6 (what to type and what to expect)
13:39:11 [raphael]: ... as a client/server implementer, I'm interested in section 5
13:40:42 [conrad]: Zakim, code?
13:40:42 [Zakim]: the conference code is 3724 (tel:+1.617.761.6200 tel:+33.4.89.06.34.99 tel:+44.117.370.6152), conrad
13:40:46 [raphael]: Jack: I'm wondering about the sub-structuring of the section 5
13:41:03 [raphael]: ... if I want to implement for file:// or rtsp://, should I read that?
13:41:13 [Zakim]: +??P1
13:41:17 [conrad]: Zakim, ??P1 is me
13:41:17 [Zakim]: +conrad; got it
13:43:34 [conrad]: Zakim, mute me
13:43:34 [Zakim]: conrad should now be muted
13:44:03 [raphael]: Raphael: no objection on the re-structuring
13:44:19 [raphael]: ... we go though each dimensions now and specify the headers syntax
13:47:24 [conrad]: the re-structuring looks great
13:50:02 [RRSAgent]: I have made the request to generate http://www.w3.org/2010/03/08-mediafrag-minutes.html raphael
13:50:34 [raphael]: Topic: 6.1 Time dimensions
13:51:02 [raphael]: Raphael: the range request is expressed in bytes ... no problem, normally range request as specified in HTTP
13:51:39 [raphael]: ... the range request is expressed in another unit ... see also ed note from Silvia at http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-protocol-Server-mapped
13:58:06 [raphael]: What we have already: http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions#Media_Fragment_Headers
14:02:47 [raphael]: I will scribe Conrad
14:02:58 [raphael]: We agree on: Range: <dimension> ':' <unit> '=' <start-pos> - <end-pos>
14:03:10 [raphael]: We are discussing the Content-Range response
14:03:21 [raphael]: ... the proposal is to start from: Content-Range: <dimension> ':' <unit> ' ' <real-start-pos> '-' <real-end-pos> '/' (<instance-length> / "*" )
14:03:30 [conrad]: ok sounds fair
14:03:37 [raphael]: ... and define <instance-length> depending on the unit
14:03:46 [conrad]: i propose to use Range-Equivalent and Content-Range-Equivalent for non-byte units
14:03:52 [raphael]: ... sorry, the dimension
14:04:50 [raphael]: ... if the dimension is time, then, Jack proposes that instance-length is originalStart-originalEnd
14:05:46 [raphael]: Example: Content-Range: t:npt 100-120/0-3600
14:05:49 [conrad]: so that existing byte range caching can continue to work, for transport of temporal or spatial responses
14:06:39 [fdenoual]: fdenoual has joined #mediafrag
14:07:35 [raphael]: Conrad, existing cache will still continue to work by overriding the Content-Range and Range headers
14:07:41 [raphael]: ... they will ust not cache it
14:07:50 [raphael]: ... except if caches understand our syntax
14:08:10 [raphael]: so why creating neww headers? rather than overriding existing ones?
14:08:15 [raphael]: s/neww/new
14:08:59 [conrad]: of course it is true that the existing caches will not catch fire or anything
14:09:03 [conrad]: :)
14:10:47 [conrad]: i think it would be useful to cache bytes 1000-2000 of the resource which is time 2min-3min
14:10:48 [raphael]: s/ust/just
14:10:59 [raphael]: we will come to that later on
14:11:16 [raphael]: with for example the Content-Range-Equivalent header ... or whatever
14:11:22 [conrad]: a cache can be told to vary on Content-Range-Equivalent
14:14:43 [raphael]: Issue is what is the mime type of the HTTP response
14:15:37 [conrad]: the origin server can respond with the full resource, Content-Range-Equivalent: npt 10-20s or whatever; a proxy can cache that, and when a new request comes through it, it can provide byte ranges of that response
14:16:21 [conrad]: Zakim, unmute me
14:16:21 [Zakim]: conrad should no longer be muted
14:17:34 [erik]: rrsagent, draft minutes
14:17:34 [RRSAgent]: I have made the request to generate http://www.w3.org/2010/03/08-mediafrag-minutes.html erik
14:18:56 [conrad]: another use case is a user agent that wants to request a media stream in chunks of say 10kB at a time
14:19:27 [conrad]: even if the resource being requested is a time range, it might first do:
14:19:46 [conrad]: Range-Equivalent: npt 10min-20min
14:19:56 [conrad]: Range: bytes 0-10000
14:19:59 [conrad]: then next do:
14:20:01 [conrad]: Range-Equivalent: npt 10min-20min
14:20:07 [conrad]: Range: bytes 10000-20000
14:20:08 [conrad]: etc.
14:20:24 [conrad]: the Range-Equivalent specifies the representation that is wanted
14:20:42 [conrad]: but the Range is a means of transporting that
14:21:05 [raphael]: Raphael: I'm the only who follow what you write :-) ... but your Range-Equivalent is missleading because it is NOT equivalent to the Range
14:21:20 [conrad]: so both these requests invoke the response header Content-Range-Equivalent: npt 10min-20min
14:21:35 [conrad]: (excuse the min specifier ;-)
14:21:59 [conrad]: raphael, ok, so call it something other than Range-Equivalent :)
14:23:02 [raphael]: Conrad, there are 3 cases defined in sections 5.2.1, 5.2.2 and 5.3.3
14:23:19 [raphael]: ... we are now talking about 5.2.2
14:26:25 [Zakim]: -conrad
14:29:16 [raphael]: ok Conrad,
14:30:41 [RRSAgent]: I have made the request to generate http://www.w3.org/2010/03/08-mediafrag-minutes.html raphael
15:00:24 [Yves]: ( *LWS element *( *LWS "," *LWS element ))
15:00:28 [Yves]: can be shown as
15:00:31 [Yves]: 1#element
15:00:45 [Yves]: 2.1 Augmented BNF
15:00:50 [Yves]: (of RFC2616)
15:29:39 [Yves]: token = 1*<any CHAR except CTLs or separators>
16:10:27 [Zakim]: -WG_room
16:10:28 [Zakim]: IA_MFWG(F2F)2:00AM has ended
16:10:29 [Zakim]: Attendees were +0329331aaaa, WG_room, conrad
16:11:23 [FD]: FD has joined #mediafrag
16:14:34 [raphael]: ACTION: Yves to modify the production rule for the track dimension in order to allow multiple comma separated values
16:14:34 [trackbot]: Created ACTION-151 - Modify the production rule for the track dimension in order to allow multiple comma separated values [on Yves Lafon - due 2010-03-15].
16:15:47 [raphael]: Multitrack API: http://www.w3.org/WAI/PF/HTML/wiki/Media_MultitrackAPI
16:32:49 [Yves]: http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-09#section-3.2
16:34:25 [raphael]: Raphael: for the time dimension, we edit live the http headers and response at http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions#Media_Fragment_Headers
16:34:47 [raphael]: Topic: 6.2: Space dimension
16:35:04 [raphael]: Raphael: The WG considers that extracting a region from an image should be done with the query parameter when transcoding is required (most of the cases). From the specification point of view, the Range and Content-Range headers are not further specified.
16:35:13 [raphael]: Topic: 6.3: Track dimension
16:54:32 [raphael]: A lot of discussion on the separator for multiple values for track in the URI: sould we use comma or semi-colon
16:54:47 [raphael]: ... we have resolved earlier today to use semi-colon, unsure now why ?
16:54:58 [raphael]: ... discuss that tomorrow morning on the phone
16:59:33 [raphael]: Raphael: we specify the Range and Content-Range header on http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions
17:03:19 [raphael]: Topic: 6.4: ID dimension
17:03:52 [raphael]: Jack: Similar to track, except that there is no sub-delim since we allow only ONE id in a fragment
17:04:00 [raphael]: ... see also: http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions#Media_Fragment_Headers
17:04:07 [RRSAgent]: I have made the request to generate http://www.w3.org/2010/03/08-mediafrag-minutes.html raphael
17:05:11 [raphael]: Topic: 7. Wrap up
17:05:18 [raphael]: ACTION-146?
17:05:18 [trackbot]: ACTION-146 -- Jack Jansen to identify and add in corrib any missing test cases for temporal fragments -- due 2010-03-03 -- OPEN
17:05:18 [trackbot]: http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/146
17:05:37 [raphael]: ACTION-147?
17:05:37 [trackbot]: ACTION-147 -- Michael Hausenblas to add all MF WG members to corrib -- due 2010-03-05 -- OPEN
17:05:37 [trackbot]: http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/147
17:05:43 [raphael]: Both must be done by tomorrow morning
17:08:20 [raphael]: Raphael: I will send a digest of today's discussion tonight
17:10:58 [raphael]: ... tomorrow, we spend 1/2 hour with everybody to decide on the comma vs semi-colon choice for multiple values for track
17:11:18 [raphael]: Jack: I'm convinced we will have problems when we combine multiple dimensions
17:11:43 [raphael]: Yves: time and tracks might mean we select on time some bytes and we activate on UA the track
17:12:20 [raphael]: Davy: NO, you select on time but you have multiple video tracks (e.g. for mobile version)
17:12:27 [raphael]: Raphael: we record the issue
17:13:48 [raphael]: Yves: we might mandate to use the ? in this case
17:14:49 [raphael]: ISSUE: Combining axis is probably not going to be done by LC, but we should write somewhere that this is doable
17:14:49 [trackbot]: Created ISSUE-16 - Combining axis is probably not going to be done by LC, but we should write somewhere that this is doable ; please complete additional details at http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/16/edit .
17:15:04 [RRSAgent]: I have made the request to generate http://www.w3.org/2010/03/08-mediafrag-minutes.html raphael
17:15:14 [raphael]: Topic: 8. AOB
17:15:28 [raphael]: [meeting adjourned]
17:15:31 [RRSAgent]: I have made the request to generate http://www.w3.org/2010/03/08-mediafrag-minutes.html raphael
17:18:19 [raphael]: ScribeOptions: -final -noEmbedDiagnostics
17:18:21 [RRSAgent]: I have made the request to generate http://www.w3.org/2010/03/08-mediafrag-minutes.html raphael
17:19:10 [Yves]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm?content-type=text/html#Quick_Start_Guide
17:21:08 [davy]: davy has left #mediafrag
18:59:50 [Zakim]: Zakim has left #mediafrag
20:47:03 [silvia]: silvia has joined #mediafrag
21:50:10 [conrad]: trout eh?
22:14:37 [silvia]: trout?
22:14:56 [Yves]: a mirc thing (windows client)
22:23:49 [silvia]: good morning!
22:23:57 [silvia]: I just made some edits :-)
22:24:13 [silvia]: introduced the Content-Range-Equivalent header
22:24:24 [silvia]: and made sure we can do multiple track names
22:24:32 [silvia]: are you working on docs?
22:27:01 [Yves]: no I'm working on paper reviews right now
22:31:12 [silvia]: ah good
23:24:02 [conrad]: conrad has joined #mediafrag