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
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]
08:23:44 [raphael]
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]
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]
08:37:04 [raphael]
Raphael: i remind you of the Resolution WG wiki page,
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]
08:39:40 [silvia]
08:39:42 [erik]
08:39:45 [jackjansen]
after femto comes atto, iirc...
08:39:47 [jackjansen]
08:39:57 [raphael]
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 raphael
08:41:05 [conrad]
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
08:45:00 [silvia]
08:45:09 [silvia]
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
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]
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]
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 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
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]
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 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:+ 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]
09:22:40 [raphael]
... transformed by the browsr
09:22:47 [raphael]
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
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]
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]
09:31:13 [silvia]
09:31:17 [foolip]
09:31:19 [jackjansen]
09:31:20 [davy]
09:31:22 [raphael]
09:31:22 [mhausenblas]
09:31:22 [Yves]
09:31:26 [erik]
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]
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]
09:38:51 [raphael]
Raphael: Silvia, yes, but it also says that it does not matter if you encode it
09:38:58 [silvia] 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 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? (
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]
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:+ 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 = ( / / )
09:58:44 [silvia]
*( "&" ( / / )
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]
10:13:08 [Yves]
say "as transcribed in pseudo-code" instead of "as an example"
10:13:29 [Zakim]
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]
10:15:26 [erik]
10:15:27 [raphael]
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]
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 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]
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 raphael
10:23:39 [Zakim]
- +0329331aaaa
10:23:53 [Zakim]
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,
10:27:32 [silvia]
10:27:33 [silvia]
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]
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]
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:+ tel:+44.117.370.6152), silvia
10:52:06 [foolip]
raphael: no, there's no phone around
10:52:11 [Zakim]
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]
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]
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]
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]
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]
11:35:58 [silvia]
tracksegment = trackprefix "=" trackparam
11:35:58 [silvia]
trackprefix = %x74. ; "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]
11:40:33 [jackjansen]
11:40:34 [Yves]
11:40:34 [davy]
11:40:35 [erik]
11:40:55 [silvia]
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 raphael
11:42:02 [silvia]
the semantics are an enumeration of the chosen tracks, right?
11:42:10 [jackjansen]
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]
11:43:43 [Yves]
11:44:43 [silvia]
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]
11:48:29 [silvia]
zakim, code?
11:48:29 [Zakim]
the conference code is 3724 (tel:+1.617.761.6200 tel:+ tel:+44.117.370.6152), silvia
11:49:15 [Zakim]
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]
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]
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]
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]
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]
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]
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 raphael
12:11:26 [Zakim]
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 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]
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]
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]
12:46:13 [raphael]
Philip, when the action was given:
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]
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, 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:+ 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]
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 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
13:58:06 [raphael]
What we have already:
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]
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]
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 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]
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]
14:29:16 [raphael]
ok Conrad,
14:30:41 [RRSAgent]
I have made the request to generate raphael
15:00:24 [Yves]
( *LWS element *( *LWS "," *LWS element ))
15:00:28 [Yves]
can be shown as
15:00:31 [Yves]
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]
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:
16:32:49 [Yves]
16:34:25 [raphael]
Raphael: for the time dimension, we edit live the http headers and response at
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
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:
17:04:07 [RRSAgent]
I have made the request to generate raphael
17:05:11 [raphael]
Topic: 7. Wrap up
17:05:18 [raphael]
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]
17:05:37 [raphael]
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]
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 .
17:15:04 [RRSAgent]
I have made the request to generate 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 raphael
17:18:19 [raphael]
ScribeOptions: -final -noEmbedDiagnostics
17:18:21 [RRSAgent]
I have made the request to generate raphael
17:19:10 [Yves]
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]
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