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