- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Thu, 19 Dec 2013 18:44:01 +0100
- To: public-webrtc@w3.org
Hi,
The minutes of our call today are available at:
http://www.w3.org/2013/12/19-webrtc-minutes.html
and copied as text below.
Please send corrections to the list.
Dom
Web Real-Time Communications Working Group Teleconference
19 Dec 2013
[2]Agenda
[2]
http://lists.w3.org/Archives/Public/public-webrtc/2013Dec/0073.html
See also: [3]IRC log
[3] http://www.w3.org/2013/12/19-webrtc-irc
Attendees
Present
fluffy, stefanh, Jim_Barnett, dom, Dini, jib, adam, ekr,
stephane, martin, DanE, hta, garykac, burn, Dan,
juberti, jesup, AndyH, +1.425.610.aaii, +1.908.541.aajj,
+1.940.735.aakk, +1.919.649.aall, +1.604.210.aamm,
+1.857.288.aahh, +1.613.435.aann , +1.940.735.aaoo,
+46.8.50.51.aaee, +46.1.07.14.aagg
Regrets
Chair
hta, stefanh
Scribe
adambe, stefanh, dom
Contents
* [4]Topics
* [5]Summary of Action Items
__________________________________________________________
<stefanh> agenda
[6]http://lists.w3.org/Archives/Public/public-webrtc/2013Dec/00
76.html
[6]
http://lists.w3.org/Archives/Public/public-webrtc/2013Dec/0076.html
<inserted> scribenick: adambe
stefanh: first we should look at the agenda from the last
meeting
... ops, wrong link
<stefanh> correction, agenda :
[7]http://lists.w3.org/Archives/Public/public-webrtc/2013Dec/00
73.html
[7]
http://lists.w3.org/Archives/Public/public-webrtc/2013Dec/0073.html
<hta> how do we tell zakim that I was wrong about the first
hta?
stefanh: we will spend the majority of the meeting discussing
the what's in/out in version 1
... then we need to discuss our next f2f
fluffy: I'm not happy with this process
stefanh: that's fine
<stefanh> minutes last meeting:
[8]http://lists.w3.org/Archives/Public/public-webrtc/2013Nov/00
71.html
[8]
http://lists.w3.org/Archives/Public/public-webrtc/2013Nov/0071.html
fluffy: the minutes does not reflect what I've said in those
meeting-
juberti: fluffy, is there anything particular?
fluffy: the meetings does not reflect what I said
ekr: why can't we record?
*me agrees with ekr
dom: I don't remember the reasons for not recording
ekr: the process with a minute taker is bad since the minute
taker can't participate in the discussion
dom: I can look into recording again
ekr: we could use a recording to fix the minutes
dom: my experience is that you don't get a good result with an
external minute taker for technical discussions
<ekr> No criticism to Adam,but I note that his notes don't even
remotely reflect what I just said :)
stefanh: anyone objecting to aproving the minutes?
fluffy: I'm not objecting
<ekr> probably because trying to type what people say,
especially me, is hard
stefanh: the minutes are approved
<ekr> jesup: exactly why I propose a recording
stefanh: let's move on to the scoping discussion
... this was brought up by juberti
... justin got an action, together with me, ekr and hta to
produce a list that we could discuss around
fluffy: asks for clarification around the process around
producing the material for discussion
... we need to discuss the list as well
... the current list reopens items that we have ruled out
before
... there are several items on this list that doesn't make
sense
<stefanh> the "list" discussed:
[9]http://lists.w3.org/Archives/Public/public-webrtc/2013Dec/at
t-0051/WebRTC_1.0_In_2FOut_-_W3C.pdf
[9]
http://lists.w3.org/Archives/Public/public-webrtc/2013Dec/att-0051/WebRTC_1.0_In_2FOut_-_W3C.pdf
juberti: the list consists of items that we have discussed but
isn't in the spec right now
fluffy: this is not a rational way to discuss what should be in
or out
ekr: queue please
... for the record, while I was involved in this.. my
involvement was to add items to list
... I don't agree with the recommendations
hta: a few points, juberti and ekr need to take some blame for
items on the list
... stefanh and me are as well
... I think what we have come up with makes sense
... it makes sense to take a position to the items in the list
... if something needs to be in the spec, or if an item
separate spec
stefanh: correction, ekr and juberti are responsible for
proposing items on the list and hta and me are responsible for
the proposed resolutions
burn: we can discuss the colums, the rows
... the colums are fine
... it's unfortunate that anything is listed under the the
desicion column
<dom> +1 to burn fwiw
burn: we should talk about the columns first, and then move on
to the rows
<hta> Dom, this is the one from 3 days ago - can you post the
link to the one Stefan posted today?
<dom> [10]Latest spreadsheet on scoping discussion
[10]
http://lists.w3.org/Archives/Public/public-webrtc/2013Dec/att-0076/Chairs__proposal_for_WebRTC_1.0_In_2FOut_-_W3C__1_.pdf
fluffy: if something is implemented is interesting
... but also if something is very useful
... the decision column should be blanked out
... we should think about what makes sense as rows
... I expect us to have mailing list discussion about rows
before making a decision
... we should classify the rows
<ekr> hta: you may want to get on the queue then
fluffy: I'd like to see real discussion about the rows so we
can determine what should be in or out
juberti: to compile this list, I've taken everything we talked
about in Seattle
... and the last two months
ekr: I'm willing to take some blame for the list
<fluffy> I would like to note in the minutes, that once again,
none of the points I made seems to make to the minutes
<dom> fluffy, you should fix the minutes by summarizing what
you said then
<fluffy> no, I am participating in the meeeting
<ekr> I see that my points aren't in the minutes either
jesup: the guiding principle should not be that we need to have
a stable version at some date
... we need to make a version that is useful for people
<ekr> to try to recap: the relevant thing to discuss is what
the principles are for making this decision, not spending small
number of seconds on each issue
<fluffy> +1 on mimimimim useful system
<ekr> +1 to jesup, obviously, since that's what I was trying to
say
<ekr> … and maybe actually did say though it wasn't minuted
<inserted> scribenick: stefanh
Dom: We all agree that we need to build a useful system, the
question is what is a useful system
<burn> +1 to ekr for today's discussion should be about
principles.
Dom: are we at the stage were we can build useful syst ontop of
webrtc, or are do we need much more time
... we need agreement on what we call useful
<dom> scribenick: dom
<ekr> ack: dom
<Zakim> dom, you wanted to comment on whether it is needed is
different from when it is needed
hta: cullen, you're suggesting is almost exactly what we've
been doing for the last 3 years
... and we're not converging
... I suggest we change mode: suggestions for things that are
not needed for a minimal useful system go to a separate spec if
possible
<jesup> jesup: We need a minimum useful system, not just a
working system. The date should not be the driving principle,
usefulness should or we get into the weeds with non-spec
extensions. The date should fall where it does; we can
constrain it to *minimum* useful to get it out ASAP, but it
must be useful.
hta: and that we try to make decisions sooner rather than later
<jesup> that was a summary of what I said, as it wasn't scribed
hta: even if we need to change some of these decisions later
... when we go beyond the principles discussion, I would like
to walk through the list of what the chairs think what the
decision should be
... and focus the discussion instead on where there is real
disagreement
<hta> ack
hta: we're here to make decisions, not to discuss how to make
them
burn: I largely agree with harald
... we can discuss whether we have enough information to make a
decision (what the columns are about)
... I feel the columns provide a reasonable amount of info
... I would like to hear the chairs recommendations
... to understand whether disagreement is on few or many points
... any discussion on defining a "useful" system will be
challenging
... people are building useful things with what is available in
implementations today (even limited to what in spec)
... but it's tricky to get agreement on what something useful
is
... but we all want to get this done
... and I think we can get there by focusing on where there are
disagreements on the chairs proposals
juberti: hta and burn said most of what I meant to say
... people out there want to see stability in the existing
stuff they're using
... esp. on things that could make or break their app
... having a 1.0 faster
... things on which we don't have a proposal for, they seem
unlikely candidates for 1.0
fluffy: no disagreement on the high level points that have been
made
... the current demos (I haven't seen production quality stuff)
... many of the fields in the spread sheet seems to be wrong
... I object to chairs asserting what we should do; they should
ask the WG
stefanh: the purpose of this list is to propose a way forward,
not to impose it
fluffy: but I'm likely to disagree with most
stefanh: then you should let us know when we get to that
fluffy: we need to verify the validity of the assessment
... also, what do you mean by "in the spec"?
stefanh: we'll talk about that when we're done with the
principles discussion
ekr: I agree it would be nice to get closure
... we keep rediscussing topics during our meetings
... but you don't repair this by cutting stuff as "closed"
... this gets repaired by setting a clearer agenda with clearly
minuted resolutions
... with agendas that focus on less items
... with the relevant set of people
... but freezing in 1.0 what is stable today isn't the way to
do that
... for devs that want stability, we need to go through the
list of features to make a list of priority
... the current API prevents a whole class of apps; e.g. stream
rejection prevents video calls on lousy connections
... if people thinks the current API is sufficient for real
world apps, they're crazy
stefanh: it's difficult to define a "useful" system
... but if you go down the use case documents, most of them can
be done with the spec as it is today
<ekr> stefanh, in that case, the problem is the use case
document
<ekr> since, as I say, we don't even let you meet 1:1 calls
where one side wants video and the other side can't support it
stefanh: it's only screen sharing that is currently not doable
Martin: ekr voiced a lot of what I wanted to say
martin: we need to get some sort of closure on issues
... we need to identify on what we do next and do it
... there are so many things we want to do - the chairs should
guide us on to closing specific issues
... lots of proposals are made, lots of discussion and noise
... and then, no decisions are made
... we should keep working on the most important things until
we feel we have done the ones we feel the most important
ekr: re we can already implement the use cases, I think this
illustrates that the use cases are insufficient
... e.g. the video call with one-way video
... currently, you can't reject a video
adambe: are you saying that we can't reject video with the
current signaling?
... we don't need to cram everything in signalling
ekr: the whole point of offer/answer was to do negotiate stuff
... if you're saying this can be done outside the offer/answer
model, this isn't providing a solution
fluffy: I agree with Martin that we need to get on closure on
issues
... if the chairs are saying we need to change the way we work,
I agree
... part of it should be "let's not reopen closed issues"
<ekr> I should also mention that the option adambe just offered
basically won't work with any non-WebRTC device when they are
the offerer
fluffy: that being said, I think we're making already good
progress
<ekr> because you will need to do a 3264-JS API gateway
fluffy: we're moving probably as fast as implementors can
follow
... I think we're still far from production-quality projects
stefanh: I don't think anyone has been proposing to remove
offer/answer
<ekr> … like you process the incoming offer and then you have
JS that examines the user's computer with JS
<ekr> and then you edit the offer appropriately
stefanh: use cases might have been more detailed, but it
remains that most of the described use cases can be implemented
<jesup> I would agree with ekr, and add that it totally kills
the idea of federation (though it's unclear if in practice
outside of non-webrtc gateways it will happen, but that case is
significant)
<juberti> Besides track rejection, what else do people think is
a dealbreaker/
stefanh: Should we try and have a look at the actual list
... ?
fluffy: can we look at the meaning of the columns before?
[11]http://lists.w3.org/Archives/Public/public-webrtc/2013Dec/a
tt-0076/Chairs__proposal_for_WebRTC_1.0_In_2FOut_-_W3C__1_.pdf
[11]
http://lists.w3.org/Archives/Public/public-webrtc/2013Dec/att-0076/Chairs__proposal_for_WebRTC_1.0_In_2FOut_-_W3C__1_.pdf
<mt> I'm going to disagree with fluffy, though not strongly
enough to voice it; the spec isn't moving, but that might be
simply due to lack of formal closure on items.
<ekr> Well, this proposal basically throws unified plan off the
bus
hta: what the columns were supposed to mean:
<juberti> I like identity too, but I have not heard app
developers telling me that it's a dealbreaker
hta: "name of the feature" points to something we have been
discussing
... and is somewhat indenpendent from the rest
... "proposal" is whether there has been a proposal
... "consensus" on how much consensus emerged from the
discussion
... "in spec" whether it is in an editor draft
burn: this just means that some form of it has been added to a
draft
... not that it is finalized
... right?
hta: yes
... an example of "no" is the rollback — there is nothing
specified for rollback (but a note to say it is TBD)
fluffy: does it include things that are normatively referenced?
hta: we're talking about things that needs to be in the W3C
spec
fluffy: but some of these things are in other specs
<juberti> Bundle control would be nice to have. But my app
would still work even if it was deferred.
fluffy: I don't like what this column is; I would like it to be
redefined
<juberti> (I would like to see it make 1.0 though_)
hta: this group is deciding on the W3C spec
... at the last F2F, we spent way too much time on IETF stuff
... as a side note
... "in impl": does anyone of the known implementation do this
feature, or some version of it?
... with notes on whether it matches the spec or not
fluffy: is this only about the two browsers? or also the apps
(e.g. the ios app)?
... this is not just browsers
hta: if you claim this app is an implementation of this spec,
tell us what it implements
... if it's a c# API that looks like ours, I would say no
fluffy: a JavaScript API
hta: the bug column references an existing bug or action when
it exists
... when it doesn't, that points to the need of some minimal
starting work for the feature
... the decision column is: whether we need to do it or not, if
we do, before 1.0 or not
... it can also that the stuff just needs to be done in IETF
(i.e. not something this group can decide)
... we also try to evaluate how separatable these things can be
... the column "break app" evaluate whether we can add a
feature without breaking apps that use the current API
... the column "own spec" tries to define whether the feature
is specifiable separately, with a proposed name of what that
spec would be
ekr: @@@
... there are cases where depending on how you define the
feature, it may or may not break existing apps
... adam suggestion on dealing with video rejection would mean
we can't change this without breaking apps that would have
hardcoded this
... how do you consider "hacky workarounds that are unlikely to
go away"?
hta: they are strong candidates for a no, indeed
... in order to discussion the high level of our proposed
decisions
... I propose we look the "can be own spec" column
<juberti> Track rejection seems like something worth including.
fluffy: I think we need to get agreement on the columns and
their values before we dive into decisions
hta: if you look at the "own spec" column
... if it can be on its own, what's the spec called, where does
it go
... some of these things are clear or will exist
<ekr> juberti: again, I'm not pressing on track rejection
because I want to change the thing that is in that cell (though
I want to) but because I think it is a nice sharp example of
how the whole mode of analysis here is wrong
<ekr> (and of the kind of analysis I think we do need)
hta: e.g. transport object, or bundle tuning
... this can be added later
fluffy: lots of people spoke of the minimum viable product as
the right criteria rather than can live in its own spec
<juberti> ekr: It seems like something everyone is picking on,
and using to implicate the whole process. Almost a strawman.
fluffy: I think we should discuss first what they mean
... I'm not ready to discuss the decisions yet
... I feel like you and your Google role are pushing hard on
this; I'm not happy about htis
<juberti> Classy.
hta: my google role has absolutely nothing to do about this
... I think you're out of line with this
fluffy: this spreadsheet was made by google, and does not
reflect what I've seen on the list
juberti: implying this is a google agenda is clearly out of
line
... this is the result of the discussions in seattle
fluffy: I'm not complaining on the list of things
... I'm complaining on the decisions
stefanh: these are not decisions
... but proposed decisions
... I was involved and have no link with Google
fluffy: I don't think Chairs should have proposed decisions
... but I think we need to get to state how we can fix the data
to be in a position to make decisions
stefanh: how do we progress on this?
juberti: we could have a strawpoll on how people feel about
these various features
... there may be too much ambiguity on some of these things
... so maybe we should first look at what is ambiguous
ekr: we shouldn't approach this as a chinese menu
... we need to look at what we want to accomplish
hta: I would like to see agreement on: if something is an IETF
spec and has no API impact, can we remove it from the list?
... if something should not worked on here, can we remove it?
fluffy: obviously we shouldn't work on things we shouldn't work
on
... this is not even part of what the WG can decide
... any specific example?
hta: handling announced and unannounced SSRCs — can we remove
those?
fluffy: @@@
hta: the spec would just need to say that the underlying
protocol needs to announce stuff
... I think it's a matter of JSEP or MSID
... what an announced/unannounced track look like is a W3C
matter, but not how it is done
ekr: if the IETF decided that unannounced SSRCs needs to be
turned into a new mediastream, then it would need something at
the API level
... the IETF would bounce back the requirement to us
hta: right
fluffy: if there is no change to the API, I have no complaint
it's not an issue
... but I've seen proposals that required API reflection
<hta> ac
<ekr> thanks to the chairs for enforcing time: I have another
meeting in 5 minutes so I appreciate them keeping this in line
burn: discussions about what we need to make this minimally
useful won't converge
... there are already strong disagreements on what's doable
with current implementations
... so we need to think about this from a standardization
perspective on separability
<juberti> I'm not sure on this. Usually tracks pop out from
setRemoteDescription. If tracks can pop out at other times, the
spec needs to talk about that. So that means spec work for
this, even if it is mainly an IETF matter.
burn: separability is not the only factor, but it's a very
important one
... no standard gets finished if everything needs to be in the
first version
<fluffy> +1 Dan and HTA that figuring out if something is
separable is important
burn: one way to figure where to draw the line is relevant to
defining 1.0
... I think we need to think at this through this
standardization perspective
+1 to burn
<Erik> +1 burn
JimBarnett: one concrete way to progress would be for everyone
to go through that list and determine the top 3/4 most
important
... to determine on what to work on next
... (independently of in/out)
<fluffy> +1 on deciding what to work on is impornatnat and
different than deciding if they are in or out
<ekr> I am fine with list discussion/polling for prioritization
stefanh: some kind of poll to prioritize
... I've also heard about people saying some things are unclear
or ambiguous
... please bring that to the list
juberti: most of these are my fault, would be happy to clarify
as needed
hta: cullen should have an action item to document where the
data is wrong
fluffy: could I instead come up with an alternative
spreadsheet?
juberti: I don't think that would help
hta: at least, that would make me understand your perspectives
<juberti> specifically, I would prefer to see a spreadsheet
with your take on the decisions, not a whole new spreadsheet
with different rows
<scribe> ACTION: fluffy to send comments on feature spreadsheet
[recorded in
[12]http://www.w3.org/2013/12/19-webrtc-minutes.html#action01]
<trackbot> Created ACTION-111 - Send comments on feature
spreadsheet [on Cullen Jennings - due 2013-12-26].
<scribe> ACTION: fluffy to send proposed alternative approach
to feature selection [recorded in
[13]http://www.w3.org/2013/12/19-webrtc-minutes.html#action02]
<trackbot> Created ACTION-112 - Send proposed alternative
approach to feature selection [on Cullen Jennings - due
2013-12-26].
fluffy: clearly we need at least more clarity on what the
features mean
... e.g. "track rejection"
stefanh: please let's make progress on the list
Summary of Action Items
[NEW] ACTION: fluffy to send comments on feature spreadsheet
[recorded in
[14]http://www.w3.org/2013/12/19-webrtc-minutes.html#action01]
[NEW] ACTION: fluffy to send proposed alternative approach to
feature selection [recorded in
[15]http://www.w3.org/2013/12/19-webrtc-minutes.html#action02]
[End of minutes]
Received on Thursday, 19 December 2013 17:44:27 UTC