Media Fragments Working Group Teleconference

<trackbot> Date: 23 June 2010

<Yves> Agenda: http://lists.w3.org/Archives/Public/public-media-fragment/2010Jun/0052.html

<scribe> scribe: raphael

<scribe> scribenick: raphael

1. Admin

PROPOSED to accept the minutes of the 6th F2F meeting

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

<davy> `+1

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

+1

<jackjansen> +1

Minutes are accepted

<erik> +1

2. Follow up of the ACTIONS

ACTION-174?

<trackbot> ACTION-174 -- Yves Lafon to produce the common syntax block -- due 2010-06-22 -- OPEN

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

close ACTION-174

<trackbot> ACTION-174 Produce the common syntax block closed

From Silvia:

scribe: Section 4.1 has the following bit of ABNF:

namevalues = namevalue *( "&" namevalue )

namevalue = name [ "=" value ]

name = fragment - "&" - "="

value = fragment - "&"

Yves: actually, we should remove this block
... this section is both invalid and un-needed
... so the whole group agrees that this section should be removed

3. Review of the whole document

ACTION-178?

<trackbot> ACTION-178 -- Silvia Pfeiffer to review the complete document, remove unnecessary editorial notes before publication -- due 2010-06-23 -- OPEN

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

close ACTION-178

<trackbot> ACTION-178 Review the complete document, remove unnecessary editorial notes before publication closed

Raphael: what do we say about RTSP processing?

Yves: for LC we should not detail the processing of this
... good to mention that the syntax is generic
... and not only for HTTP

<silvia> +q

Silvia: the messages that go over the protocol is protocol dependant

<davy> Note that we have a description on our wiki about RTSP: http://www.w3.org/2008/WebVideo/Fragments/wiki/UA_Server_RTSP_Communication

Silvia: what we can do is to say how media fragments URI syntax can be mapped to RTSP messages
... but don't say how, since we don't have time

<Yves> adding "This specification is not defining the protocol aspect of RTSP handling of media-fragment."

Davy: we could just re-use this wiki page and adapt it to the latest syntax

Yves: problem is that we will need to test this through implementation

<silvia> +q

Yves: while a WG note would not need to be tested

Davy: but we have an implementation of this!

Silvia: I know people who also wants to have an implementation ... so it must not be difficult

Yves: I think RTSP is useful ... but I suggest to have it in another document
... but I want to speed up the process
... so I prefer to have another document

<silvia> if we think it is hard to include RTSP after LC, I think it would make more sense to include it now

Jack: I think it is a good idea to put it into another document
... let me explain why it is a bad idea to include RTSP handling at *this* stage
... the fact that we have one working implementation does not mean we understand fully the mechanism

<silvia> RTSP has been developed with the fragment functionality as part of the protocol

Jack: except if Davy ensures he got all issues fixed

Davy: I'm also in favor of putting this into another document ... and take our time to check how it works

<silvia> how hard is it to include this later into the document then, when we make it a separate document now?

<silvia> why would it delay the LC?

<silvia> no, not to remove it later - to update it later with more information

<Yves> delay the LC as we would need to review it

<Yves> I am not happy in adding at the last minute something as big as that without _any_ review before

<Yves> and reviewing introduces delays

<silvia> we don't know everything about caching right now either - there will be more updates necessary

<silvia> so, if it is easy to add things later, I am fine

<erik> +1 to Silvia

<silvia> but if that would be a problem, I object to making it a separate document, because we are ripping apart where ppl can find information about media fragments

<Yves> why?

<silvia> I would need to tell ppl: find the spec of URI fragments here, but how to use it with rtsp in this other doc

<Yves> if someone want to use mediafrag in protocol 'bar' later on does it mean that we will have to revise our doc to add this new protocol?

Michael: we can include it and ask the community for feedback

<Yves> no silvia, the rtsp spec will refer to the uri syntax one

<silvia> it's not like rtsp is a new protocol

<Yves> we expect people to be smart enough to understand what they read no?

<silvia> Yves: it's still 2 docs

Jack: not at LC stage, you're supposed to have scope the spec

<Yves> and?

<Yves> do we want to merge rfc2616 and 3987 as well in our doc?

Jack: this discussion is procedural
... we all agree we will like to have rtsp in the spec
... the question is whether adding it now, add a cost of 2 months we don't have!
... does it give us enough benefits ?

Erik: what is wrong of adding it now, few days of copy-pasting
... and review it during LC

<silvia> I agree

<silvia> it also gives ppl from that community a need to review it

Yves: it is not healthy to add things not which hasn't been reviewed
... LC should have been published 6 months ago

Davy: do we want to be LCWD asap or do we want to cover RTSP?

Jack: the second document is not that important ... since under my understanding, the problem of implementing with RTSP is trivial
... and if it turns to not be trivial, then it will fit a 2.0 version of the spec

<erik> again +1 to Silvia

Silvia: but if if is trivial, then why not including it now in the document

Jack: what I have said is that with *my* understanding, it is trivial
... but I might be very wrong

Silvia: problem is that you will not trust a note
... and this is pushing people of our spec
... i'm unhappy in splitting the document into multiple docs

Raphael: looking at the charter
... "The Group will focus on developing a mechanism to uniquely identify a temporal fragment within an audio or video object, that is independent of the underlying audio or video codec in use, and will also investigate the delivery of the requested resource to allow full or partial media retrieval using at least the HTTP protocol. "

<silvia> zaim, mute me

Silvia: do we really need to understand all the bits of the spec?

Erik: I fully agree with what Silvia has said

Yves: looking at our traffic on our mailing list, not that many emails about rtsp
... we haven't received enough attention and review on this point

<jackjansen> same point as yves

<silvia> rtsp got less review because it was much simpler and needed no discussion

Raphael: the wiki page has never been included in the doc so that might explain the lack of attention

Yves: having everything in one doc is silly anyway, even html5 is slowly moving away from this
... I don't see studies that people will not look at 2 documents

Raphael: this is a problem of compactness

<silvia> proposal: could we have a few days of review for the rtsp section and then make the decision?

<silvia> by when do we need to make the decision to move the doc to LC?

Jack: the documents is a workaround solution

<silvia> one more week should be enough to learn more about rtsp and make a decision either way

Jack: the problem is not looking at our wiki page which is ok
... the problem is looking at the rtsp spec
... and make sure we are not saying stupid things

<silvia> I think you can read the rtsp spec within an hour, honestly

<silvia> I would look at it

Silvia: yes, I have already used rtsp implementations

Raphael: I wonder Yves how would you rate your knowledge of rtsp?

Silvia: i think for temporal fragment over rtsp, there is no problem
... we might have problems with other dimensions
... as Yves said, the problem of cutting the media depending on the codec is the same
... we just have the protocol to fix

Davy: I have also a number of concerns about smpte time codes for rtsp

<Yves> raphael, I would qualify it as 'very rusty'

Davy: rtsp does not have the content mapping
... should we define it as well for rtsp ?
... I think there are things that MUST been discussed before
... and I don't think it is feasible in one week

Silvia: assuming we do not know all the details, does not make sense to at least include what we have now in the spec?
... actually, the best way to have feedback on what we have is to include it in the document
... afterwards, we might take out this part if we have not enough technical knowledge
... I see this section as mature as others

Raphael: I think I disagree with this latest statement

<Yves> I am strongly against putting a whole new section that didn't get _any_ review and raises lots of question in a LC document

<Yves> in a regular WD yes, but not on a LC

<silvia> what comes after LC?

<jackjansen> Example of problem witrh rtsp: interaction with section 10.0 REDIRECT

<silvia> I think we will have a second LC anyway

Jack: I think we should not do it, not include rtsp into this doc
... we need much serious thoughts

<jackjansen> http://tools.ietf.org/html/rfc2326#page-39

<silvia> ok, I won't stand in the way

<Yves> we can have multiple LC for sure

<Yves> even CR->LC phases

<Yves> note that I completely agree to have a new WD for RTSP, that we can fasttrack if the doc is in good shape

Raphael: I suggest to add a link towards a wiki page to get feedback

<mhausenblas> +1

<silvia> isnt' that like admitting we aren't finished with the doc for LC?

Raphael: and a generic sentence stating the importance of the genericity of the URI syntax

<silvia> ok, fair enough

<erik> +1

<silvia> I retract my objection

<davy> +1

<silvia> 0

Raphael: 0

<jackjansen> +1

<scribe> ACTION: troncy to address RTSP handling, pointing to the wiki page for the processing, making sure the syntax is stated to be generic [recorded in http://www.w3.org/2010/06/23-mediafrag-minutes.html#action01]

<trackbot> Created ACTION-179 - Address RTSP handling, pointing to the wiki page for the processing, making sure the syntax is stated to be generic [on Raphaël Troncy - due 2010-06-30].

Section 7.4 should it be removed?

ALL: yes

Raphael: ok, I will remove it

close ACTION-178

<trackbot> ACTION-178 Review the complete document, remove unnecessary editorial notes before publication closed

<silvia> requirements have been turned into normal text

<silvia> done :)

<silvia> but the requirements document is referenced at the start of the document

Raphael: multiple tracks, is it all clear now?

Silvia: no, sometimes we say one, and sometimes multiple ones
... it must be consistent
... my question is: do we translate this into one header in the request?
... the question is do we want to have multiple occurrences of "track" in the URI and a single one in the header?

Jack: do we need to escape semi-colon?

<silvia> question is: do we agree that there are several "track" parameters in the URI, but only a single on in the HTTP header with the different tracks separated by semicolon

Yves: mutiple tracks mean many many many packets
... we cannot handle this in a multi-part message response

Davy: the response might be a redirect
... the problem is for the request

Yves: the plan is to use the comma in the request as a separator

Jack: people are aware that the fact we are using %escaping UTF-8 strings in the headers?

<silvia> I can make these changes, yes

4. ISSUE-17

Silvia: we are waiting for i18n answer

Jack: we need to take a decision when they reply

Yves: it will be a LC issue
... no problem

5. AOB

Raphael: Does WebM fit in our table?

<silvia> thanks, bye!

<scribe> ACTION: davy to add the WebM codec into our fitting table [recorded in http://www.w3.org/2010/06/23-mediafrag-minutes.html#action02]

<trackbot> Created ACTION-180 - Add the WebM codec into our fitting table [on Davy Van Deursen - due 2010-06-30].

Summary: document edited once more today, and then LCWD issue, publication hopefully tomorrow

[meeting adjourned]