Media Fragments Working Group Teleconference

<trackbot> Date: 08 March 2010

trackbot, start telecon

<trackbot> Meeting: Media Fragments Working Group Teleconference

<trackbot> Date: 08 March 2010

1. Administrative

<scribe> scribenick: raphael

<erik> http://www.w3.org/2008/WebVideo/Fragments/wiki/FifthF2FAgenda

Raphael: Minor changes in the agenda
... 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 :-)

2. Media Fragments syntax

First thing to consider: WG decision for expressing wall-clock time code

<Yves> http://www.ietf.org/rfc/rfc3339.txt

<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?

<davy> +1

<silvia> +1

<erik> +1

<jackjansen> after femto comes atto, iirc...

<jackjansen> +1

+1

RESOLUTION: we will express wall-clock time code with RFC3339

<conrad> +1

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> ups

<silvia> http://www.w3.org/2002/09/wbs/42785/MFRAGSYNTAXQUOTE/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

ACTIOn-150?

<trackbot> ACTION-150 -- Erik Mannens to summarize the discussion on the quotes in a mail or on the wiki -- due 2010-03-03 -- OPEN

<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/150

<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

<guillaume> examples?

<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

Yes PHilip

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?

<foolip> yes

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-

<silvia> encoded."

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.

<silvia> +1

<foolip> +1

<jackjansen> +1

<davy> +1

+1

<mhausenblas> +1

<Yves> =

<erik> +1

<jackjansen> ?

<guillaume> ?

<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> 6.2.2.2. Percent-Encoding Normalization <- explicitly talks about not encoding them

<silvia> yes, I agree

Raphael: two remaining problems
... 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 section 4.2.5
... 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

now: b)

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...

See http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#fragment-structure

<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

<guillaume> ok

<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.

close ACTION-150

<trackbot> ACTION-150 Summarize the discussion on the quotes in a mail or on the wiki closed

close ACTION-143

<trackbot> ACTION-143 Move 5.1.5 into a new section closed

close ACTION-144

<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> e.g.

<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> <SEQ=SEG.ACK><CTL=RST>

<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

<foolip> indeed

3. Structure of the spec

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

yes silvia

<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

<jackjansen> fully

<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> yes

<foolip> so jackjansen is suggesting that implementors should ignore the spec and accept other input than the ABNF allows?

no

<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

<foolip> ok

<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

4. Multiple tracks

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> 4.2.3

<silvia> tracksegment = trackprefix "=" trackparam

<silvia> trackprefix = %x74.72.61.63.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

<jackjansen> +1

<Yves> =

<davy> +1

<erik> +1;

<silvia> +1

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?

<jackjansen> corect

5. Multiple but equivalent Content-Range headers

Silvia: I'm happy to have a new header called Content-Range-Equivalent

<silvia> 5.2.2

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

<Yves> http://tools.ietf.org/html/rfc2047

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> foo=bar

<Yves> in the uri: foo=b%XXr

<Yves> in the header:

<Yves> Toto: foo=bar

<Yves> or

<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> http://www.example.com/foo#t=%34

<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

thanks philip

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

6. HTTP headers syntax

close ACTION-141

<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

ACTION-132?

<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

<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/132

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

ok

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

close ACTION-132

<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?

<Yves> http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-09#section-5.4.1

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 expect)
... 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 re-structuring
... we go though each dimensions now and specify the headers syntax

<conrad> the re-structuring looks great

6.1 Time dimensions

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 dimension
... 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 it
... except if caches understand our syntax

so why creating neww headers? rather than overriding existing ones?

s/neww/new

<conrad> of course it is true that the existing caches will not catch fire or anything

<conrad> :)

<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> etc.

<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

ok Conrad,

<Yves> ( *LWS element *( *LWS "," *LWS element ))

<Yves> can be shown as

<Yves> 1#element

<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

<Yves> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-09#section-3.2

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

6.2: Space dimension

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.

6.3: Track dimension

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

6.4: ID dimension

Jack: Similar to track, except that there is no sub-delim since we allow only ONE id in a fragment
... see also: http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions#Media_Fragment_Headers

7. Wrap up

ACTION-146?

<trackbot> ACTION-146 -- Jack Jansen to identify and add in corrib any missing test cases for temporal fragments -- due 2010-03-03 -- OPEN

<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/146

ACTION-147?

<trackbot> ACTION-147 -- Michael Hausenblas to add all MF WG members to corrib -- due 2010-03-05 -- OPEN

<trackbot> http://www.w3.org/2008/WebVideo/Fragments/tracker/actions/147

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 .

8. AOB

[meeting adjourned]