[minutes] Dec 19 teleconf

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